JP3892002B2 - リソース割り当て方法及びプログラム - Google Patents

Description

本発明は、クライアントに提供するホスティング環境の構成をクライアントのニーズに合わせて変更する技術に関する。

インターネット上のオンラインシステムや、企業内ＩＴシステムにおけるバッチ処理システムは、ネットワーク接続されている複数の計算機リソース上で稼動している複数のアプリケーションプログラムによって構成されている。これらのアプリケーションプログラムは、計算機リソース上で直接実行されているものもあるが、アプリケーションサーバと呼ばれるインタープリタを含むミドルウェア上で解釈、実行される場合もある。

このように、アプリケーションシステムは、稼動しているアプリケーションプログラムと、アプリケーションプログラムが稼動する環境に分けられる。ここでは、アプリケーションプログラムの稼動する環境、すなわち、計算機リソースあるいは、アプリケーションサーバのようなプログラムリソースによって構成されるシステムをホスティング環境と呼ぶ。

このホスティング環境は前述の様にネットワーク分散システムであり、大規模なシステムほどシステム保守管理のためのコストは大きくなる。従って、このホスティング環境の構築、および保守管理をアウトソーシングする場合が一般的である。アウトソーシング先は、データセンタあるいはサービスプロバイダと呼ぶサービス業者である。ホスティング環境の種類としては、企業ホームページの構築のためのＷｅｂサーバ環境や、メールサーバ機能があり、データセンタはホスティング環境を利用するクライアントのアウトソーシングニーズに合わせて提供するサービスを決定している。

また、トータル保守コスト(TCO: Total Cost of Ownership)の削減の観点から、近年企業内ＩＴシステムの計算機リソースの有効利用が注目されており、企業内ＩＴシステムにおいても、給与計算バッチ処理プログラムなどのアプリケーションプログラムを稼動させるホスティング環境を共用する必要性がでてきている。企業のＩＴシステム管理部門は、部門として提供するホスティング環境を企業内ＩＴシステムに最適であるように決定しなければならない。

このように、データセンタあるいは企業内ＩＴシステム管理部門は、提供するホスティング環境の構成を適切に決定しなければならないという課題をもっている。例えば、データセンタにおいては、クライアントのホスティング環境に対するニーズを分析し、その結果に応じて最小限の投資で効果的にホスティング環境を構成するシステムリソースを導入する必要がある。その際、データセンタ自身の経営ポリシーや予算的制約の範囲内で、これを実行しなければならない。

同様に、企業内ＩＴシステム管理部門においても、社内のアプリケーションプログラム群によるホスティング環境ニーズに適合する形で、システムリソースを導入する必要がある。その際には、企業自身の運営ポリシーや予算的制約を勘案しなければならない。このように、ある種の制約条件下での、リソース構成の決定を行うことは一般にリソースプラニングと呼ばれている。

この種のリソースプラニングに関する技術としては、リソースの供給先におけるリソースの需要状態情報及び供給状態情報を取得し、リソース配分の計画を支援するものが知られている（特許文献１）。

また、業務処理プログラムのリソース使用状況を業務別に収集して、リソース配分改善や性能改善のためのリソース分析を業務別に実行するものが知られている（特許文献２）。
特開平１１−３５３３５８号公報 特開２００２−２７８７８０号公報

しかしながら、前記従来技術では、ホスティング環境を提供するサービスプロバイダが提供しているリソースを、顧客のリソース割り当て要求に対して、自動的に最適な構成にすることができないという問題がある。

さらに近年、運用コスト削減の観点や、信頼性強化の観点から、データセンタあるいは企業内システムの広域連携（広域グリッド）に関する要求が高まってきている。しかし、広域連携を考慮した場合には、広域連携におけるクライアントからのリソース要求についての情報を、完全に入手するのは難しいという問題があり、次に提供するリソースの構成を最適化するのが難しい。

そこで本発明は、上記問題点に鑑みてなされたもので、ホスティング環境として提供しているシステムリソースと、クライアントからのリソース割り当て要求内容に応じて、次に提供するシステムリソースの構成を最適な構成にすることを目的とし、特に、広域連携においてもクライアントのニーズに応じたシステムリソースを最適な構成にすることを目的とする。

本発明は、クライアントから受け付けたリソースの割り当て要求と、現在のリソースの構成に基づいて、変更すべきリソースの構成を決定することで、クライアントのニーズに応じたリソースの構成を自動的に構築する。また、前記変更すべきリソースの構成の決定は、リソース構成の変更履歴を蓄積し、次回以降の構成変更時には前記変更履歴に基づいて変更すべきリソースの構成を決定し、前記リソース構成の変更履歴を蓄積するステップは、前記リソースの割り当て要求を当該環境で実行できたかどうかの履歴として蓄積する。

したがって、本発明は、クライアントのニーズに応じたリソースの構成を自動的に構築することが可能となって、様々なクライアントニーズに対応可能な最適のリソース構成を提供することができる。

また、クライアントのニーズが変動する場合であっても、システムリソースの利用効率が向上するように、リソースの構成を自動的に変更することが可能となる。

以下、本発明の一実施形態を添付図面に基づいて説明する。

図１は、複数の計算機リソースをクライアントに対して提供するデータセンタＡに、本発明を適用した場合を示す。

図１において、データセンタＡは、顧客等に提供するための複数の管理対象リソース５０１を保有している。管理対象リソース５０１は、例えば、サーバマシン、ストレージ装置やミドルウェア、アプリケーションソフトウェア等の計算機リソースで構成され、特にリソースの種別を限定するものではない。

そして、データセンタＡには、クライアントからのリソース割り当て要求と、保有する管理対象リソース５０１から、次にデータセンタＡが提供すべきリソースをプラニングする、リソースプラニングシステムを実行する管理サーバマシン４０１と、この管理サーバマシン４０１に対する指令を行う管理者用クライアントマシン４０３と、が備えられる。

これら管理サーバマシン４０１、管理対象リソース５０１、管理者用クライアントマシン４０３は、管理用ネットワーク２０２を介して接続されている。管理用ネットワーク２０２とのネットワーク接続３０１の形態については、有線・無線等の様々な接続手段を利用可能であり、本実施形態では特に限定しない。

また、管理サーバマシン４０１及び管理対象リソース５０１は、顧客あるいは顧客が提供するサービスのエンドユーザが利用可能とするため、ホスティング用ネットワーク２０１にも接続され、顧客用クライアントマシン（クライアントコンピュータ）４０２へ管理対象リソース５０１の提供を行う。なお、顧客用クライアントマシン４０２は、データセンタＡの管理ドメイン外からの接続手段によってホスティング用ネットワーク２０１に接続している。

データセンタＡの管理ドメイン（例えば、データセンタや企業内のＩＴシステム）１０１は、データセンタＡのシステム管理者が各サーバマシン及び管理対象リソース５０１を操作できる権限をもつ範囲を示している。

なお、各サーバマシン及び各顧客用クライアントマシン４０２は、ＣＰＵ、メモリ、ストレージ装置を備えるものである。

次に、管理サーバマシン４０１で実行されるリソースプラニングシステム全体のプログラム構成について説明する。

図２は、管理サーバマシン４０１にインストールされたプログラム構成を表しており、管理サーバマシン４０１上では、管理対象リソース５０１を顧客用クライアントマシン４０２に割り当てるリソース割り当てシステム６０１と、管理対象リソース５０１の構成を管理する構成管理システム６０２と、顧客用クライアントマシン４０２からのリソース割り当て要求に基づいて割り当てるべき管理対象リソース５０１を決定するリソースプラニングシステム６０３と、が稼動している。

リソースプラニングシステム６０３には、所定のアルゴリズムにより割り当てるリソースを適切に調整するリソースプラニングエンジン部７０３と、リソースの割り当て状況を管理するリソース割り当て情報管理部７０４、リソースプラニングエンジン部７０３への入出力を制御するリソースプラニング制御部７０５と、管理者用クライアントマシン４０３からの指令をリソースプラニング制御部７０５へ伝達する管理者用インタフェース部７０６が含まれる。

以上の環境において、本実施形態で示すリソースプラニングシステムの前提である、リソース割り当てシステム６０１と構成管理システム６０２によるリソース割り当て処理の流れについて説明する。

まず、顧客用クライアントマシン４０２上で稼動する顧客用クライアントプログラム８０１は、リソースプラニングシステム６０３のリソース割り当て情報管理部７０４に対して、リソースの割り当てを要求する。

次に、リソース割り当て情報管理部７０４は、前記リソース割り当て要求の内容を、図３に示すリソース割り当て情報管理テーブル９０１に保存し、リソース割り当て要求をリソース割り当てシステム６０１に転送する。図３のリソース割り当て情報管理テーブル９０１は、リソースを割り当て要求のあった顧客用クライアントマシン４０２のユーザＩＤ９０１１と割り当て要求の時刻９０１２を対としたレコードを有する。リソース割り当て情報管理テーブル９０１には、ユーザＩＤ９０１１と割り当て要求の時刻９０１２をキーとした各レコードに、割り当て要求内容９０１３（例えば、割り当て要求がサーバの場合、ＯＳの種類、バージョン、メモリ容量等）と、要求に対する実行の有無を示す割り当て結果９０１４から構成される。

リソースの割り当て情報管理部７０４からリソース割り当て要求を受け取ったリソース割り当てシステム６０１は、構成管理システム６０２に対して、リソース割り当て要求の情報に含まれる属性情報に基づいて図４に示す構成情報管理テーブル９０２上で検索を行う。図４に示す構成情報管理テーブル９０２は、管理対象リソース５０１の識別子であるリソースＩＤ９０２１毎にレコードが形成される。各レコードには、可動の可否を示す状態９０２２と、リソースの種類などを示す属性情報９０２３（例えば、管理対象リソース５０１がサーバマシンの場合、ＯＳの種類、バージョン、メモリ容量等）と、割り当ての実行状況９０２４が含まれる。

構成管理システム６０２は、上記構成情報管理テーブル９０２を管理しており、割り当て要求に含まれる属性情報と、前記属性情報９０２３に合致するリソースが見つかった場合には、リソース割り当てシステム６０１に検索結果である構成情報を通知し、構成情報管理テーブル９０２に当該リソースが割り当て済みであることをマークする。

リソース割り当てシステム６０１は、前記通知された構成情報をリソース割り当て情報管理部７０４に転送し、リソース割り当て情報管理部７０４は割り当て結果をリソース割り当て情報テーブル９０１に保存した上で、顧客用クライアントプログラム８０１にリソース割り当て結果を通知する。

以上の結果として、リソース割り当て情報テーブル９０１にリソース割り当て要求・結果の履歴が残る。

次に、図６は、リソースプラニングシステム６０３で行われるリソースプラニング処理の一例を示すメインフローチャートを示す。以下、このフローチャートに基づいて、リソースプラニング処理の流れを説明する。

このフローチャートは、システム管理者が管理者用クライアントマシン４０３上で図８に示すリソースプラニングシステムのコンソール画面１１０１において、プラニング処理開始の指示を出したとき（開始指示インタフェース１１０４においてシステム管理者が「開始」ボタン１１０６を押したとき）に開始される。その際、制約条件作成インタフェース１１０３を用いて、システム管理者の所望する制約条件を入力しておく。入力した制約条件は、制約条件一覧表示インタフェース１１０２に一覧（図中、トータル予算、サーバマシンなど、制約対象としての金額、管理対象リソース５０１）として表示されている。なお、上記コンソール画面１１０１は、管理者用クライアントマシン４０３において実行される管理者用プログラム８０２により提供され、これらのシステム管理者用インタフェースを用いた操作は全て管理者用インタフェース部７０６（図２参照）を通してリソースプラニング制御部７０５に転送され、処理される。

システム管理者によってリソースプラニングが開始されると、次に、リソースプラニング制御部７０５は、リソースプラニングエンジン部７０３を起動する（ステップ１００１）。この際に、リソースプラニング制御部７０５は前記システム管理者によって設定された制約条件情報をリソースプラニングエンジン部７０３に受け渡す。

起動されたリソースプラニングエンジン部７０３は、独自のプラニングアルゴリズムを実行する（ステップ１００２）。特定のアルゴリズムを実行するリソースプラニングエンジン部７０３に対して、リソースプラニング制御部７０５は汎用的な機能を提供しており、あらゆるリソースプラニングアルゴリズムに対して共通に必要な機能、すなわち、リソース割り当て情報取得機能および構成情報取得機能を備えている。

図７は上記プラニングアルゴリズムの一例を示しており、本アルゴリズムは、過去のリソース割り当ての履歴に基づいて、提供リソース（管理対象リソース５０１）を適切に増減するものである。ここで、図７のフローチャートに従って、具体的な処理内容を説明する。

まず、起動されたリソースプラニングエンジン部７０３はリソースプラニング制御部７０５に対して、構成情報の取得要求を出す。リソースプラニング制御部７０５は構成管理システム６０２から構成情報管理テーブル９０２の内容を取得し、リソースプラニングエンジン部７０３に返信する（ステップ１００７）。

次に、リソースプラニングエンジン部７０３は、同様にリソースプラニング制御部７０５に対して、リソース割り当て情報の取得要求を出す。リソースプラニング制御部７０５はリソース割り当て情報管理部７０４からリソース割り当て情報テーブル９０１の内容を取得し、リソースプラニングエンジン部７０３に返信する（ステップ１００８）。

これらの情報を取得したリソースプラニングエンジン部７０３は、リソース割り当て情報の統計計算を行う(ステップ１００９)。前記統計計算の結果、特定リソースへのリソース割り当て要求が集中しているかどうか判断を行い(ステップ１０１０)、また、リソース割り当て要求があったが、提供するリソースが無かったために割り当て不能となったリソース割り当て要求があったかどうかの判断を行い（ステップ１０１１）、どちらかの条件を満たした場合に、当該リソース（要求のあったリソース）を追加するという判断を下す（ステップ１０１２）。

また、長期（予め設定した期間。例えば、数日など）にわたってリソース割り当て要求が行われていないリソースがあるかどうかの判断を行い（ステップ１０１３）、リソース割り当て要求があった場合には当該リソースを削減するという判断を下す（ステップ１０１４）。

最後に、以上の結果により変更されるリソース構成が、システム管理者のポリシールールを満たしているかどうかの判断を行い（ステップ１０１５）、該当している場合には、ポリシールールに対するアクションを実行する（ステップ１０１６）。このポリシールールは、図５で示すように、リソースプラニング制御部７０５のポリシー管理テーブル９０３で定義されるものである。このポリシー管理テーブル９０３は、ポリシーの識別子となるポリシーＩＤ９０３１と、このポリシーＩＤ９０３１に対応したポリシーの条件９０３２及びアクション９０３３が関連付けられている。

この例では、ポリシーＩＤ「１００１」には、Ｒｉｎｕｘサーバマシンの合計が１０台未満になったとき、という条件９０３２に対して、Ｒｉｎｕｘサーバマシンの合計を１０台にする、というアクション９０３３が定義されている。

以上のプラニングアルゴリズム実行の結果、リソースプラニングエンジン部７０３によるリソース構成変更内容が決定する。本実施形態では、図３のリソース割り当て情報テーブル９０１の２行目に示すリソース割り当て要求（ユーザＩＤ＝「ｂａｒ」、割り当て結果「ＮＧ」）が拒否されていることから、図７のステップ１０１１、１０１２によって当該リソースを追加する判断がなされ、リソースの変更内容は、図９のプラニング結果確認画面１１０５の様に決定される。なお、図９は、リソースプラニングシステム６０３からリソースの割り当て変更の通知を受けた管理者用プログラム８０２で行われる表示の一例である。

図６において、システム管理者が前記リソース構成変更内容を確認の上「承認」ボタンを押すことで、変更内容が確定する（ステップ１００３）。システム管理者による承認が得られなかった場合には、図８の制約条件作成インタフェース１１０３において、ポリシー・制約条件の再設定を行い（ステップ１００４）、再度リソースプラニングエンジン部７０３が起動される。システム管理者による承認が得られた場合には、リソースプラニング制御部７０５は、リソース変更内容に従って、実際にリソース構成の変更を行う（ステップ１００５）。また、変更したリソース構成情報は構成管理システム６０２に保存される(ステップ１００６)。保存されるリソース構成情報は、図４の構成情報管理テーブル９０２に対して、図９のリソース構成変更内容を反映したものであり図１０の構成情報管理テーブル９０２に示す通りである（４行目が新規追加されたリソースを表している）。

以上のリソースプラニング処理がシステム管理者によって繰り返して指示され、実行されることによって、データセンタＡの提供リソース（管理対象リソース５０１）は常に顧客（顧客用クライアントマシン４０２）によるリソース割り当て要求の傾向に適合したものとなる。

このようにして、現在ホスティング環境として提供しているデータセンタＡが提供するシステムリソース内容と、クライアントからのリソース割り当て要求内容およびその結果に応じて、次に提供するシステムリソース内容を決定することが可能となる。

そして、クライアントからのリソース要求情報を用いて、リソースプラニングを行うことが可能になり、顧客の要望に添ったリソースを自動的に構成することができる。さらに、クライアントによるホスティング環境（データセンタＡ）の利用履歴に応じて、提供するリソース内容を、自動的にプラニングすることが可能になる。

さらに、データセンタＡ（あるいはサービスプロバイダ）のシステム管理者による運営ポリシーや制約条件が入力可能となり、データセンタＡのドメインに応じてシステムの構成をカスタマイズすることができる。

また、企業内ITシステムは、各種申請処理、給与計算などの日常的なバッチジョブを処理するシステムや、各種オンラインシステムによって構成されており、システム規模が大規模なものになっている。従って、これらの業務処理のためのシステムリソースの利用効率の向上は大きな課題となっており、本発明のリソースプラニング方法によって企業内システムにおける様々なアプリケーションに対して導入すべきシステムリソース構成を最適に決定することが可能となり、リソースを有効に利用することでのコスト削減が可能になる。

＜第２実施形態＞
図１１は、第２の実施形態を示す、データセンタＡを含むシステム全体のブロック図である。

本実施形態では、複数の計算機リソースをクライアント（顧客用クライアント）に対して提供する、あるデータセンタＡを想定し、あらかじめ蓄積しておいた、クライアントからのリソース割り当て要求と、データセンタＡ内の提供リソース（管理対象リソース５０１）の構成と、広域管理ドメイン（グローバル管理ドメイン１０２）全体で提供されているリソース構成情報とに基づいて、次にデータセンタＡが提供すべきリソースをプラニングする構成を示す。なお、広域管理ドメインは、複数の計算機リソースが存在する広域グリッドあるいはビジネスグリッドとしても良い。また、ビジネスグリッドとは、科学技術計算分野において分散した計算機リソースを有効利用するために用いられるグリッドコンピューティング技術を、アプリケーション統合のためのサービス技術と融合させたもので、グリッド技術をビジネス分野にも適用可能にするものである。

まず、前提となるネットワーク、及びサーバ計算機等の構成について述べる。図１１は本実施形態における、データセンタＡを含むシステム全体の構成を表している。データセンタＡは複数の管理対象リソース５０１を保有しており、管理サーバマシン４０１及び管理者用クライアントマシン４０３と共に管理用ネットワーク２０２に接続されている。ネットワーク接続３０１の種類については、有線・無線等の様々な接続形態を利用可能であり、本実施形態では特に限定しない。また、管理サーバマシン４０１及び管理対象リソース５０１は顧客あるいは顧客が提供するサービスのエンドユーザが利用可能とするため、ホスティング用ネットワーク２０１にも接続されている。データセンタＡの管理ドメイン１０１は、データセンタＡのシステム管理者が操作できる権限をもつ範囲を示している。

なお、管理サーバマシン４０１、管理対象リソース５０１、管理者用クライアントマシン４０３、管理用ネットワーク２０２、ホスティング用ネットワーク２０１は、前記第１実施形態と同様な構成であり、以下、前記第１実施形態と同様な構成のものについては、同一の符号を付す。

顧客用クライアントマシン４０２および、広域管理サーバマシン４０４及びデータセンタＢの管理ドメイン１０７は、インターネット２０３に接続しており、インターネット２０３とデータセンタＡのホスティング用ネットワーク２０１はゲートウェイ４０５によって接続されている。なお、データセンタＢは上記データセンタＡと同様に構成され、管理対象リソースを顧客用クライアントマシン４０２に提供する。

そして、広域管理サーバマシン４０４は、広域管理ドメイン１０２上のリソース割り当て情報またはリソース構成情報を参照し、収集したリソースの割り当て情報を顧客用クライアントマシン４０２や管理サーバマシン４０１に公開するグローバルレジストリとして機能する。

次に、システム全体のプログラム構成について説明する。図１２は本実施形態におけるプログラム構成を表しており、管理サーバマシン４０１上では、前記第１実施形態と同様に、リソース割り当てシステム６０１、構成管理システム６０２、リソースプラニングシステム６０３が稼動している。リソースプラニングシステム６０３には、前記第１実施形態と同様のリソースプラニングエンジン部７０３、リソース割り当て情報管理部７０４、リソースプラニング制御部７０５、管理者用インタフェース部７０６に加えて広域管理サーバマシン４０４と連携する広域連携処理部７０７を設けたものである。

また、広域管理サーバマシン４０４上では、グローバル管理ドメイン１０２上でリソースの割り当てを行う広域リソース割り当てシステム６０４と、グローバル管理ドメイン１０２上の管理対象リソースの情報を管理する広域構成管理システム６０５が稼動している。

広域構成管理システム６０５には、図１３で示すような広域構成情報管理テーブル９０４が含まれており、その内容としてはデータセンタＡを含む、それぞれのローカル管理ドメインの提供しているリソースの構成情報が含まれている。

広域構成情報管理テーブル９０４は、図１３において、グローバル管理ドメイン１０２上の管理対象リソースの識別子であるリソースＩＤ９０４１毎にレコードが形成される。各レコードには、リソースの種類などを示す属性情報９０４２（例えば、管理対象リソース５０１がサーバマシンの場合、ＯＳの種類、バージョン、メモリ容量等）と、リソースの数（台数）９０４３、リソースの位置（ドメイン）９０４４が含まれる。

以上の環境において、本実施形態で示すリソースプラニングシステムの前提として、広域管理サーバマシン４０４上で稼動する広域リソース割り当てシステム６０４、広域構成管理システム６０５、リソース割り当てシステム６０１及び構成管理システム６０２による広域でのリソース割り当て処理の流れについて説明する。

まず、顧客用クライアントマシン４０２上で稼動する顧客用クライアントプログラム８０１は、広域リソース割り当てシステム６０４に対して、リソースの割り当て要求を出す。広域リソース割り当てシステム６０４は広域構成管理システム６０５に対して、リソース割り当て要求情報に含まれる属性情報に基づいて検索を行う。

広域構成管理システム６０５は、図１３に示す広域構成情報管理テーブル９０４を管理しており、前記属性情報に合致するリソースが見つかった場合には、該当するリソースを提供している管理ドメイン名（この場合にはデータセンタＡ）を返信する。

広域リソース割り当てシステム６０４は、受け取った管理ドメイン名を用いて、例えばデータセンタＡのアクセスポイントをＤＮＳサーバなどにより解決し、データセンタＡのリソースプラニングシステム６０３のリソース割り当て情報管理部７０４にリソース割り当て要求を転送する。

次に、リソース割り当て情報管理部７０４は前記リソース割り当て要求内容を、図３に示すリソース割り当て情報テーブル９０１に保存し、リソース割り当て要求をリソース割り当てシステム６０１に転送する。

リソース割り当て要求を受け取ったリソース割り当てシステム６０１は、構成管理システム６０２に対して、リソース割り当て要求情報に含まれる属性情報に基づいて検索を行う。構成管理システム６０２は図４に示した構成情報管理テーブル９０２を管理しており、前記属性情報に合致するリソースが見つかった場合には、リソース割り当てシステム６０１に検索結果である構成情報を通知し、構成情報管理テーブル９０２に当該リソースが割り当て済みであることをマークする。

リソース割り当てシステム６０１は前記通知された構成情報をリソース割り当て情報管理部７０４に転送し、リソース割り当て情報管理部７０４は割り当て結果をリソース割り当て情報テーブル９０１に保存した上で、広域リソース割り当てシステム６０４にリソース割り当て結果を通知する。広域リソース割り当てシステム６０４は顧客用クライアントプログラム８０１に前記通知されたリソース割り当て結果を転送する。

以上の結果として、リソース割り当て情報テーブルにリソース割り当て要求・結果の履歴が残っていることを前提として、以下では、リソースプラニング処理の流れを説明する。リソースプラニング処理のメインフローは図１４に示すとおりであり、実施形態１で説明した図６のフローに対して、プラニング結果であるリソース変更内容を広域構成管理システム６０５に対して登録するステップ１０３２が追加されている以外は同じである。

図１４では、前記第１実施形態と同様にリソースプラニングエンジン部７０５によりリソースプラニングエンジン部７０３を起動して、リソース構成変更内容を決定する。

そして、システム管理者が前記リソース構成変更内容を確認の上「承認」ボタンを押すことで、変更内容が確定する（ステップ１００３）。システム管理者による承認が得られなかった場合には、図８の制約条件作成インタフェース１１０３において、ポリシー・制約条件の再設定を行い（ステップ１００４）、再度リソースプラニングエンジン部７０３が起動される。システム管理者による承認が得られた場合には、リソースプラニング制御部７０５は、リソース変更内容に従って、実際にリソース構成の変更を行う（ステップ１００５）。また、変更したリソース構成情報は構成管理システム６０２に保存される(ステップ１００６)。保存されるリソース構成情報は、図４の構成情報管理テーブル９０２に対して、図９のリソース構成変更内容を反映したものであり図１０の構成情報管理テーブル９０２に示す通りである（４行目が新規追加されたリソースを表している）。

図１５は、図６におけるステップ１００２で実行される広域対応のリソースプラニングアルゴリズムの一例を示しており、本アルゴリズムは、データセンタＡおよび広域において提供されているリソースの傾向および、過去のデータセンタＡにおけるリソース割り当ての履歴に基づいて、提供リソース構成を適切に変更するものである。

以下、図１５のフローチャートに従って、具体的処理内容を説明する。まず、起動されたリソースプラニングエンジン部７０３はリソースプラニング制御部７０５に対して、データセンタＡの提供するリソースの構成情報の取得要求を出す。リソースプラニング制御部７０５は構成管理システム６０２から構成情報管理テーブル９０２の内容を取得し、リソースプラニングエンジン部７０３に返す（ステップ１００７）。

次に、リソースプラニングエンジン部７０３は、同様にリソースプラニング制御部７０５に対して、広域におけるリソース構成情報の取得要求を出す。リソースプラニング制御部７０５は、広域連携処理部７０７に対して広域のリソース構成情報の取得を要求し、広域連携処理部７０７は、広域管理サーバマシン４０４上で稼動する広域構成管理システム６０５に対して構成情報を要求する。広域構成管理システム６０５が広域連携処理部７０７に要求された構成情報を返すと、広域連携処理部７０７はリソースプラニング制御部７０５に構成情報を転送する。さらに、リソースプラニング制御部７０５はリソースプラニングエンジン部７０３に構成情報を転送する（ステップ１０１７）。

次に、リソースプラニングエンジン部７０３は、同様にリソースプラニング制御部７０５に対して、ローカルのリソース割り当て情報の取得要求を出す。リソースプラニング制御部７０５は、リソース割り当て情報管理部７０４からリソース割り当て情報テーブル９０１の内容を取得し、リソースプラニングエンジン部に返す（ステップ１００８）。

これらの情報を取得した、リソースプラニングエンジン部７０３は、リソース割り当て情報の統計計算を行う（ステップ１００９）。

次にリソースプラニングエンジン部７０３は、前記取得した広域のリソース構成情報を統計し、その中で、減少傾向にあるリソースがあった場合、ローカル（管理ドメイン１０１内）で同系リソースの他リソースに占める割合が広域の割合よりも大きいかどうかを判断する（ステップ１０１８）。

前記ステップ１０１８の結果、リソースのローカル割合が広域割合よりも大きかった場合には、当該リソースへの割り当て要求が一定値以上行われているかを判断し（ステップ１０１９）、一定値以上ない場合には、後述する想定リターン指標値を減算する（ステップ１０２０）。

また、逆に、取得した広域のリソース構成情報を統計した中で、増加傾向にあるリソースがあった場合、同系リソースの他リソースに占める割合が広域の割合よりも小さいかどうかを判断する（ステップ１０２１）。

前記ステップ１０２１の結果、リソースのローカル割合が広域割合よりも小さかった場合には、当該リソースへの割り当て要求が一定値以下しか行われていないかどうかを判断し（ステップ１０１９）、一定値以下でない場合には、想定リターン指標値を加算する（ステップ１０２０）。

以上の処理において想定リターン指標値は、当該データセンタＡにおける、リソースの利益予想（または収益の指標）を示す相対的な値である。

最後にリソースプラニングエンジン部７０３は、前記想定リターン指標値の総和を最大化し、かつ、予めシステム管理者によって図８のコンソール画面を用いて設定された図１６に示す制約条件を満たす、リソースの構成割合を、線形計画問題解法によって導出し、導出結果をプラニング結果とする（ステップ１０２４）。

図１６は、リソースプラニング制御部に格納された制約条件テーブル９０５を示す。

この制約条件テーブル９０５は、制約条件の識別子となるポリシーＩＤ９０５１と、このポリシーＩＤ９０３１に対応した条件９０５２、条件を判定するオペレータ９０５３、しきい値となる値９０５４が関連付けられている。例えば、第１行目のポリシーＩＤ＝Ｐ１００１では、サーバマシン数が５００台以下になるような制約条件を示し、ＩＤ＝Ｐ１００２では、月額の合計予算が２０００万円以下になるような制約条件を示している。

本実施形態では、データセンタＡが初期状態で提供しているリソース構成は図１３の広域構成情報管理テーブル９０４に示すとおりであり、１行目で示すリソースが想定リターン指標値に対して不足しており、３行目で示すリソースが過剰であると仮定する。

前記ステップ１０２４の結果、データセンタＡにおけるプラニング結果である構成情報は、図１７の構成種別管理テーブル９１２に示す通りとなる。この構成種別管理テーブルは、管理対象リソース５０１の種別を示す識別子としてのリソースＩＤ９１２１と、このリソースＩＤ９１２１に対応した属性情報９１２２及び数９１２３が関連付けられている。つまり、この構成種別管理テーブル９１２は、上記図４に示した構成情報管理テーブル９０２を管理対象リソース５０１の種別毎に集計したレコードから構成される。そして、リソースプラニング制御部７０５が、広域連携処理部７０７を介してこの構成種別管理テーブル９１２を広域構成管理システム６０５の広域構成情報管理テーブル９０４に通知することで、広域構成管理システム６０５の情報は最新のものとなる。

以上のように、リソースプラニング処理をシステム管理者によって指示され実行することによって、データセンタＡの提供リソースは広域（グローバル管理ドメイン１０２）における提供リソースの傾向に合致するようにリソースの構成を変更し、データセンタＡの管理対象リソースを顧客のニーズに応じた構成にすることで、利益を最大化できる。

また、広域構成情報管理システム６０５で、リソースを提供する各管理ドメインのリソースの種類と数を管理し、公開することで、広域連携において各ドメインが提供しているリソースを容易に把握でき、提供する管理対象リソースの指標とすることができる。

また、複数の企業からのアウトソーシング先であるデータセンタＡでは、様々なクライアントニーズに対応して、かつデータセンタＡの利益を最大化するシステムリソース構成を決定しなくてはならない。本発明によって、このシステムリソース構成のプラニングを自動的に行うことが可能になり、データセンタＡのＩＴインフラ投資コストの最適化と利益拡大が可能になる。
＜第３実施形態＞
本第３の実施形態では、複数の計算機リソースをクライアントに対して提供する、あるデータセンタＡを想定し、予め蓄積しておいた、クライアントからのリソース割り当て要求と、データセンタＡ内の提供リソースの構成と、過去に行ったプラニング結果の履歴とに基づいて、次にデータセンタＡが提供すべきリソースを決定する、リソースプラニングシステムの動作について説明する。

本実施形態における、前提となるネットワーク、及びサーバ計算機等の構成は、前記第１実施形態におけるシステム構成（図１）と同様である。

次に、システム全体のプログラム構成について説明する。図１８は本実施形態におけるプログラム構成を表しており、前記第１実施形態におけるプログラム構成（図２）に対して、リソースプラニングシステム６０３内にプラニング履歴蓄積部７０８を追加しており、過去に行ったリソースプラニング結果の履歴を蓄積・参照できるようになっている。

図１９で示すようにプラニング履歴蓄積部７０８はプラニング履歴テーブル９０６を備えている。プラニング履歴テーブル９０６は、プラニングを実行した日付（日時）９０６１に対応して、プラニングを実施した管理者９０６２、実施したプラニングの内容を示すプラニング結果アクション９０６３、対象リソースの属性値９０６４から構成される。

図２０は、本実施形態におけるリソースプラニング処理のメインフローチャートを示しており、前記第１実施形態におけるメインフローチャート図６に対して、リソースプラニングを行った結果を保存するステップ１０２５を追加している。

以下では、図１９のプラニング履歴テーブル９０６に示すようなプラニング結果が履歴として保存されている場合の、リソースプラニングエンジン部７０３のアルゴリズムについて、図２１のフローチャートに基づいて説明する。

リソースプラニングエンジン部７０３はリソースプラニング制御部７０５に起動されると、リソース構成情報の取得（ステップ１００７）、リソース割り当て情報の取得（ステップ１００８）、リソースへの要求量を統計（ステップ１００９）を前記第１実施形態と同様に実行し、次にリソースプラニング制御部７０５に対して、過去のプラニング結果の履歴情報を要求する。

リソースプラニング制御部７０５は、過去のプラニング結果の履歴をプラニング結果蓄積部７０８に対して問い合わせ、結果をリソースプラニングエンジン部に転送する。（ステップ１０２７）。プラニング履歴を取得したリソースプラニングエンジン部７０３は、過去に増設したリソースの割り当て状況を計算し、一定以上の割り当て率である場合に、当該リソースをさらに増加する判断を行う（ステップ１０２７，１０２８）。逆に過去に削減したリソースに対しても割り当て状況を計算し、一定以下の割り当て率である場合には、当該リソースをさらに削減する判断を行う（ステップ１０２９，１０３０）。その後、前記第１実施形態と同様にステップ１０１５、１０１６においてポリシールールの適用を行った結果をプラニング結果として決定する。

以上のプラニング実行結果を図２０のステップ１０２５において、再度次回のプラニングに用いるために保存しておく。なお、本実施形態においては、図３のリソース割り当て情報テーブル９０１に示すリソース割り当て要求が発行されたとすると、図１９のプラニング履歴テーブル９０６の１行目に示す時刻に追加されたリソースに対してリソース割り当て要求が発行されたこととなり、当該リソースを追加するプラニング結果となる。従って、前記リソースプラニング処理終了後のデータセンタＡのリソース構成は、図２２の構成情報管理テーブル９０２に示す通りとなる（５行目が新規追加されたリソースを示している）。
また、プラニング結果の履歴はシステム管理者によって確認可能とするため、管理者用インタフェース部７０６は、プラニング結果履歴確認機能を提供し、図２３に示すようにプラニング結果履歴確認画面１１０７で過去のプラニング結果であるリソース変更履歴を列挙させることができる。

このように、クライアントからのリソース要求情報の履歴を用いて、リソースの増加または減少傾向を判定することでリソースプラニングを行うことが可能になる。

＜第４実施形態＞
図２４は、第４の実施形態を示し、複数の計算機リソースをクライアントに対して提供する、あるデータセンタＡを想定し、あらかじめ蓄積しておいた、クライアントからのリソース割り当て要求と、データセンタＡ内の提供リソースの構成に基づいて、次にデータセンタＡが提供すべきリソースをプラニングし、その結果、必要となるソフトウェアライセンスの追加・削減を行うリソースプラニングシステムの動作について説明する。

まず、前提となるネットワーク、及びサーバ計算機等の構成について述べる。図２４は本実施形態における、データセンタＡを含むシステム全体の構成を表している。前記第２実施形態におけるシステム構成図（図１１）に対して、インターネット２０３に接続されているライセンスサーバマシン４０６を追加しており、データセンタＡとゲートウェイ４０５を介して接続されている。ライセンスサーバマシン４０６は、データセンタＡが必要とするソフトウェアライセンスを動的に追加・削除するためのサーバ機能を提供している。

次に、システム全体のプログラム構成について説明する。図２５は本実施形態におけるプログラム構成を表しており、前記第１実施形態におけるプログラム構成（図１）に対して、リソースプラニングシステム６０３内にライセンス管理部７０９を追加しており、ライセンスの動的追加・削減機能をリソースプラニング制御部に対して提供する。図２６はライセンス管理部７０９の保持しているライセンス管理テーブル９０７の内容であり、データセンタＡの所有するライセンス資産の一覧を示している。ライセンス管理テーブル９０７は、ソフトウェアの種別を示すライセンス名９０７１と、ライセンスの期間９０７２、ライセンスの数量から構成される。

以下では、本実施形態におけるリソースプラニング処理の流れを説明する。本実施形態においては、リソースプラニング処理のメインフローは図６に示す前記第１実施形態で説明したものと同じである。

図２７は、本実施形態におけるプラニングアルゴリズムのフローチャートを示しており、ステップ１０２７、１０２８において、リソースプラニングの結果、現在データセンタＡの保持しているソフトウェアライセンス数に対して増減が発生した場合、リソースプラニングエンジン部７０３はリソースプラニング制御部７０５に対して、ライセンス数の変更を要求する。

リソースプラニング制御部７０５はライセンス数の変更要求をライセンス管理部７０９に転送し、ライセンス管理部７０９は、ライセンスサーバマシン４０６上で稼動する動的ライセンス付与システム８０２に対して、前記ライセンス変更要求を行い、結果をライセンス管理テーブル９０７に保存する（図２６）。

ここで、ライセンスの取得処理以外を前記第１実施形態と全く同じ条件でプラニング処理を実行したとすると、前記図６のメインフローの実行終了後のライセンス管理部７０９内のライセンス管理テーブル９０７の内容は、図２８に示す通りとなる。つまり前記第１実施形態の図９に示したリソース構成変更内容に伴って、「Rinux OS」ライセンスが追加されている。

＜第５実施形態＞
図２９は、第５の実施形態を示し、複数の計算機リソースをクライアントに対して提供する、あるデータセンタＡを想定し、システム管理者のポリシーによって複数のリソースプラニングアルゴリズムから適応するものを選択し、あらかじめ蓄積しておいた、クライアントからのリソース割り当て要求と、データセンタＡ内の提供リソースの構成に基づいて、次にデータセンタＡが提供すべきリソースをプラニングするリソースプラニングシステムの動作について説明する。

本実施形態における、前提となるネットワーク、及びサーバ計算機等の構成は前記第１実施形態におけるシステム構成（図１）と同様である。

次に、システム全体のプログラム構成について説明する。図２９は本実施形態におけるプログラム構成を表しており、前記第１実施形態におけるプログラム構成図（図２）と比較して、リソースプラニングシステム６０３内にアルゴリズムバインディング部７１０と、複数のリソースプラニングエンジン部７０３を追加しており、システム管理者のポリシーによって任意のリソースプラニングアルゴリズムを選択できるようになっている。

図３２は、本実施形態におけるリソースプラニング処理のメインフローチャートを示しており、前記第１実施形態におけるメインフローチャート図６に対して、複数のリソースプラニングエンジン部７０３からポリシーに対応したものを選択するステップ１０２９を追加している。以下では、図３０のポリシー情報が設定されている場合の、リソースプラニングシステムの動作について説明する。

最初に、リソースプラニング制御部７０５は、図３０に示すポリシー管理テーブル９０３の内容のうち、最初の行に着目し、当該ポリシー情報がオペレーティングシステムを指定するポリシー種別であることが判明するため、アルゴリズムバインディング部７１０に対して、当該ポリシー種別情報と共に、リソースプラニングエンジン部７０３の起動を要求する。

アルゴリズムバインディング部７１０は、指定されたポリシー種別を元に、あらかじめ設定されている図３１のバインディングテーブル９０８を検索し、リソースプラニングエンジン部ＩＤを取得し、ＩＤに対応するリソースプラニングエンジン部を起動する。起動されたリソースプラニングエンジン部７０３は前記第１実施形態と同様にプラニングアルゴリズムを実行する。次に、リソースプラニング制御部７０５は他のポリシー情報に対しても同様の処理を行う。なお、バインディングテーブル９０８は、リソースの割り当て情報種別９０８１とリソースプラニングエンジン部ＩＤ９０８２から構成される。

ポリシー管理テーブル９０３のポリシー種別に応じて起動するリソースプラニングエンジン部７０３を自動的に切り換えることができるので、リソース割り当て要求の種別によってリソースプラニングエンジンを選択・切り替えすることが可能になり、あらゆるリソース割り当て要求に対して容易に対応できる。

＜第６実施形態＞
図３３は、第６の実施形態を示し、複数の計算機リソースをクライアントに対して提供する、データセンタＡおよびデータセンタＢを想定し、あらかじめ蓄積しておいた、クライアントからデータセンタＡに対するリソース割り当て要求と、データセンタＡおよびデータセンタＢ内の提供リソースの構成に基づいて、次にデータセンタＡが提供すべきリソースをプラニングするリソースプラニングシステムの動作について説明する。

なお、本実施形態においてデータセンタＡとデータセンタＢは管理ドメイン（サイト）が異なるものの、提携関係にあるものとする。

まず、前提となるネットワーク、及びサーバ計算機等の構成について述べる。図３３は本実施形態における、データセンタＡおよびデータセンタＢ含むシステム全体の構成を表している。データセンタＡの構成については前記第２実施形態２のものと同様である。データセンタＢは複数の管理対象リソース５０２を保有しており、管理サーバマシン４０８及び管理者用クライアントマシン４０７と共に管理用ネットワーク２０５に接続されている。また、管理サーバマシン及び管理対象リソースは顧客あるいは顧客が提供するサービスのエンドユーザが利用可能とするため、ホスティング用ネットワーク２０４にも接続されている。データセンタＢの管理ドメイン１０３は、データセンタＢのシステム管理者が操作できる権限をもつ範囲を示している。

顧客用クライアントマシン４０２および、広域管理サーバマシン４０４は、インターネット２０３に接続しており、インターネット２０３とデータセンタＢのホスティング用ネットワーク２０４はゲートウェイ４０６によって接続されている。

次に、システム全体のプログラム構成について説明する。図３４は本実施形態におけるプログラム構成を表しており、データセンタＡ内の構成については、前記第２実施形態のものと同様である。

データセンタＢの管理サーバマシン４０２上では、リソース割り当てシステム６０４、構成管理システム６０５、リソースプラニングシステム６０６が稼動している。

リソースプラニングシステム６０６には、リソースプラニングエンジン部７１３、リソース割り当て情報管理部７１２、リソースプラニング制御部７１４、管理者用インタフェース部７１５、及び広域連携処理部７１１が含まれる。

また、広域管理サーバマシン４０４上では前記第２実施形態と同様に、広域リソース割り当てシステム６０４、広域構成管理システム６０５が稼動している。広域構成管理システム６０５にはデータセンタＡ、Ｂの広域構成種別管理テーブル９０４Ａ、９０４Ｂ（図３５、図３６）が含まれており、その内容としてはデータセンタＡおよびデータセンタＢを含む、各ローカル管理ドメインの提供しているリソース構成情報が含まれている。

以上の環境を前提として、以下でリソースプラニング処理の流れを説明する。本実施形態においては、リソースプラニング処理の大きな流れは図１４に示した前記第２実施形態で説明したものと同じである。

図３７は、本実施形態におけるデータセンタＡのリソースプラニングエンジン部７０３で処理されるプラニングアルゴリズムのフローチャートを示している。

まず、ステップ１００７、１０１７において、データセンタＡおよび広域におけるリソース構成情報を取得する。この処理は前記第２実施形態のものと同様である。次にリソースプラニングエンジン部７０３は、リソースプラニング制御部７０５に対して、提携しているデータセンタＢのリソース構成情報の取得を要求する。

リソースプラニング制御部７０５は広域連携処理部７０７に対して、リソース構成情報取得要求を転送し、広域連携制御部７０７はデータセンタＢの広域連携制御部７１１に対してリソース構成情報の取得要求を行う。データセンタＢの広域連携処理部７１１は当該要求に基づいて、リソースプラニング制御部７１４に対してリソース構成情報の取得を指示し、リソースプラニング制御部７１４は構成管理システム６０５よりリソース構成情報を検索し、得られたリソース構成情報を通知する。リソース構成情報は、前記手順の逆順に転送され、リソースプラニングエンジン部７０３に受け渡される（ステップ１０３０）。

次に、リソースプラニングエンジン部７０３はステップ１００８〜１０２４を前記第２実施形態と同様に実行し、リソースプラニング結果を得る。ただし、前記取得しておいたデータセンタＢのリソース構成情報とプラニング結果である構成情報を比較し、データセンタＢの保有している構成情報は除外して、最終的なプラニング結果とする（ステップ１０３１）。

本実施形態では、データセンタＡ及びＢが初期状態で提供しているリソース構成は図３５、図３６の広域構成情報管理テーブル９０４Ａ、Ｂに示すとおりであり、前記第２実施形態と同一条件でデータセンタＡのプラニングを行い、前記ステップ１０３１においてデータセンタＢに含まれるリソースを排除することで、プラニング結果であるデータセンタＡのリソース構成情報は、図３８、３９の広域構成情報管理テーブル９０４Ａ、Ｂに示す通りとなる。このようにデータセンタＢの構成情報を取得し、プラニングに反映させることで、提携関係にあるデータセンタ間の提供リソースの住み分けが可能になり、提携データセンタ間のトータルコスト削減に効果がある。

なお、請求項１の発明において、前記制約条件またはポリシー情報は、管理者用クライアントから受け付けて、これら制約条件またはポリシー情報の設定を行う、としてもよい。

以上、本発明によれば、様々なクライアントニーズに対応して、かつデータセンタの利益を最大化するシステムリソース構成のプラニングを自動的に行うことができるので、データセンタのリソース割り当てシステムに適用することができる。また、業務処理のためのシステムリソースの利用効率を自動的に向上させることができるので、企業内ITシステム等に適用することができる。

第１の実施形態を示すシステムの全体構成図。 管理サーバにインストールされたプログラムの構成図。 リソースの割り当て情報テーブルの一例を示す説明図。 構成情報管理テーブルの一例を示す説明図。 ポリシー管理テーブルの一例を示す説明図。 プラニングの処理のメインルーチンを示すフローチャート。 リソースプラニングエンジン部で行われるプラニングアルゴリズムの一例を示すフローチャート。 リソースプラニングシステムのコンソール画面の一例を示す説明図。 同じく、ソースプラニングシステムのコンソール画面の一例を示し、リソースプラニングの結果を示す説明図。 構成情報管理テーブルの一例を示し、リソースプラニングの結果を反映させた状態を示す説明図。 第２の実施形態を示し、システムの全体構成図。 管理サーバにインストールされたプログラムの構成図。 広域構成情報管理テーブルの一例を示す説明図。 プラニング処理のメインルーチンを示すフローチャート。 リソースプラニングエンジン部で行われるプラニングアルゴリズムの一例を示すフローチャート。 構成種別管理テーブルの一例を示す説明図。 制約条件管理テーブルの一例を示す説明図。 第３の実施形態を示し、管理サーバのプログラムの構成図。 プラニング履歴テーブルの一例を示す説明図。 プラニングの処理のメインルーチンを示すフローチャート。 リソースプラニングエンジン部で行われるプラニングアルゴリズムの一例を示すフローチャート。 構成情報管理テーブルの一例を示す説明図。 リソースプラニングシステムのコンソール画面の一例を示す説明図。 第４の実施形態を示し、システムの全体構成図。 管理サーバにインストールされたプログラムの構成図。 ライセンス管理テーブルの一例を示す説明図。 リソースプラニングエンジン部で行われるプラニングアルゴリズムの一例を示すフローチャート。 プラニングの結果を示し、ライセンス管理テーブルの一例を示す説明図。 第５の実施形態を示し、管理サーバのプログラムの構成図。 ポリシー管理テーブルの一例を示す説明図。 バインディングテーブルの一例を示す説明図。 プラニングの処理のメインルーチンを示すフローチャート。 第６の実施形態を示し、システムの全体構成図。 管理サーバにインストールされたプログラムの構成図。 データセンタＡの構成情報管理テーブルの一例を示す説明図。 データセンタＢの構成情報管理テーブルの一例を示す説明図。 リソースプラニングエンジン部で行われるプラニングアルゴリズムの一例を示すフローチャート。 プラニングの結果を示し、データセンタＡの構成情報管理テーブルの一例を示す説明図。 プラニングの結果を示し、データセンタＢの構成情報管理テーブルの一例を示す説明図。

符号の説明

４０１ 管理サーバ
４０２ 顧客用クライアントマシン
４０３ 管理者用クライアントマシン
５０１ 管理対象リソース
６０１ リソースの割り当てシステム
６０２ 構成管理システム
６０３ リソースプラニングシステム
７０３ リソースプラニングエンジン部
７０４ リソースの割り当て情報管理部
７０５ リソースプラニング制御部
７０６ 管理者用インタフェース

Claims (18)

1. サーバ、ネットワーク、ストレージまたはソフトウェアを含むリソースを、複数のクライアントに対して提供する環境において、該環境が提供するリソースの構成の構築を支援するリソースプラニング方法であって、
   前記クライアントからのリソースの割り当て要求を受け付けて、該リソースの割り当て要求の内容に応じてリソースを割り当てるステップと、
   リソースプラニングの開始指示を受け付けるステップと、
   前記開始指示を受け付けたときに、現在のリソースの構成を取得するステップと、
   前記リソースの割り当て要求の内容の履歴と、現在のリソースの構成に基づいて、変更すべきリソースの構成を決定するステップと、を含み、
   前記変更すべきリソースの構成を決定するステップは、リソース構成の変更履歴を蓄積するステップを有し、次回以降の構成変更時には前記変更履歴に基づいて変更すべきリソースの構成を決定し、
   前記リソース構成の変更履歴を蓄積するステップは、前記リソースの割り当て要求を当該環境で実行できたかどうかの履歴として蓄積することを特徴とするリソースプラニング方法。
2. 前記変更すべきリソースの構成は、前記環境に新たに設置すべきサーバ、ストレージ装置、または新たに導入すべきソフトウェアを含むことを特徴とする請求項１に記載のリソースプラニング方法。
3. 前記変更すべきリソースの構成を決定した後で、さらに、前記環境の管理者の承認を受け付けるステップを含むことを特徴とする請求項２に記載のリソースプラニング方法。
4. 前記リソースの割り当て要求を受け付けて、該リソースの割り当て要求の内容に応じてリソースを割り当てるステップは、受け付けたリソースの割り当て要求を蓄積するステップを含み、
   前記変更すべきリソースの構成を決定するステップは、前記蓄積した割り当て要求の履歴と現在のリソースの構成に基づいて、変更すべきリソースの構成を決定することを特徴とする請求項１に記載のリソースプラニング方法。
5. 前記変更すべきリソースの構成を決定するステップは、予め設定されたリソース構成変更の制約条件またはポリシー情報に基づいて、変更すべきリソースの構成を決定することを特徴とする請求項１に記載のリソースプラニング方法。
6. 前記変更すべきリソースの構成を決定するステップは、前記割り当て要求に対して割り当てが実行されていないリソースまたは割り当て要求が集中するリソースを増大する一方、所定の期間割り当て要求のないリソースを減少させることを特徴とする請求項４に記載のリソースプラニング方法。
7. 前記リソースの構成の変更結果を、前記クライアントまたは異なるドメインに公開するステップを含むことを特徴とする請求項１に記載のリソースプラニング方法。
8. 前記現在のリソースの構成を取得するステップは、異なるドメインのリソースの構成を取得するステップを含み、
   前記変更すべきリソースの構成を決定するステップは、
   前記異なるドメインのリソースの増減を検出するステップと、
   前記増減のあったリソースについて、同一ドメイン内のリソース全体に対する比率を求めるステップと、
   前記増減のあったリソースに対する同一ドメイン内への割り当て要求を取得するステップと、
   前記比率と割り当て要求に基づいて、同一ドメイン内のリソースの構成変更を行うステップと、を含むことを特徴とする請求項１に記載のリソースプラニング方法。
9. 前記同一ドメイン内のリソースの構成変更を行うステップは、前記比率と割り当て要求に基づいて収益の指標を示す値を求め、当該収益の指標に基づいてリソースの構成を変更することを特徴とする請求項５に記載のリソースプラニング方法。
10. 前記リソースの構成の変更結果に基づいて、当該リソースに対応するソフトウェアのライセンスの変更を要求するステップを含むことを特徴とする請求項１に記載のリソースプラニング方法。
11. サーバ、ネットワーク、ストレージまたはソフトウェアを含むリソースを、複数のクライアントに対して提供する環境において、該環境が提供するリソースの構成の構築を支援するプログラムであって、
    前記クライアントからのリソースの割り当て要求を受け付けて、該リソースの割り当て要求の内容に応じてリソースを割り当てる手順と、
    リソースプラニングの開始指示を受け付ける手順と、
    前記開始指示を受け付けたときに、現在のリソースの構成を取得する手順と、
    前記リソースの割り当て要求の内容の履歴と、現在のリソースの構成に基づいて、変更すべきリソースの構成を決定する手順と、を含み、
    前記変更すべきリソースの構成を決定する手順は、リソース構成の変更履歴を蓄積する手順を有し、次回以降の構成変更時には前記変更履歴に基づいて変更すべきリソースの構成を決定し、
    前記リソース構成の変更履歴を蓄積する手順は、前記リソースの割り当て要求を当該環境で実行できたかどうかの履歴として蓄積することをコンピュータに機能させることを特徴とするプログラム。
12. 前記リソースの割り当て要求を受け付けて、該リソースの割り当て要求の内容に応じてリソースを割り当てる手順は、前記受け付けたリソースの割り当て要求を蓄積する手順を含み、
    前記変更すべきリソースの構成を決定する手順は、前記蓄積した割り当て要求の履歴と現在のリソースの構成に基づいて、変更すべきリソースの構成を決定することを特徴とする請求項１１に記載のプログラム。
13. 前記変更すべきリソースの構成を決定する手順は、予め設定されたリソース構成変更の制約条件またはポリシー情報に基づいて、変更すべきリソースの構成を決定することを特徴とする請求項１１に記載のプログラム。
14. 前記変更すべきリソースの構成を決定する手順は、前記割り当て要求に対して割り当てが実行されていないリソースまたは割り当て要求が集中するリソースを増大する一方、所定の期間割り当て要求のないリソースを減少させることを特徴とする請求項１２に記載のプログラム。
15. 前記リソースの構成の変更結果を、前記クライアントまたは異なるドメインに公開する手順を含むことを特徴とする請求項１１に記載のプログラム。
16. 前記現在のリソースの構成を取得する手順は、異なるドメインのリソースの構成を取得する手順を含み、
    前記変更すべきリソースの構成を決定する手順は、
    前記異なるドメインのリソースの増減を検出する手順と、
    前記増減のあったリソースについて、同一ドメイン内のリソース全体に対する比率を求める手順と、
    前記増減のあったリソースに対する同一ドメイン内への割り当て要求を取得する手順と、
    前記比率と割り当て要求に基づいて、同一ドメイン内のリソースの構成変更を行う手順と、を含むことを特徴とする請求項１１に記載のプログラム。
17. 前記同一ドメイン内のリソースの構成変更を行う手順は、前記比率と割り当て要求に基づいて収益の指標を示す値を求め、当該収益の指標に基づいて変更すべきリソースの構成を決定することを特徴とする請求項１６に記載のプログラム。
18. 前記リソースの構成の変更結果に基づいて、当該リソースに対応するソフトウェアのライセンスの変更を要求する手順を含むことを特徴とする請求項１１に記載のプログラム。

Images