情報処理装置、判定方法、判定プログラム、およびプロビジョニングシステム
【課題】個々のシステムリソースごとに診断の最適な実施契機を得て、プロビジョニングを効果的に行う。
【解決手段】システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合に当該システムリソースを診断対象とし、また、使用中のシステムリソースの負荷状況値が閾値を超えた場合には、未使用のシステムリソースを診断対象とし、未使用であり最新の診断結果が正常であるシステムリソースを、追加対象のシステムリソースとして割り当てる。
【解決手段】システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合に当該システムリソースを診断対象とし、また、使用中のシステムリソースの負荷状況値が閾値を超えた場合には、未使用のシステムリソースを診断対象とし、未使用であり最新の診断結果が正常であるシステムリソースを、追加対象のシステムリソースとして割り当てる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報処理装置、判定方法、判定プログラム、およびプロビジョニングシステムに関し、特に、予防診断を制御する情報処理装置、判定方法、判定プログラム、およびプロビジョニングシステムに関する。
【背景技術】
【０００２】
情報／通信のシステム、機器等においては、ユーザの需要を予想し、サーバやネットワーク設備などの未使用のシステムリソースを事前に用意しておき、ユーザの要求に応じてそれを割り当てて迅速にサービスの提供を行うプロビジョニング技術がある（たとえば、特許文献１）。
【０００３】
また、コンピュータシステムにおいて、予備プロセッサや予備ＣＥＬＬ等のシステムリソースを定期的に診断する技術がある（たとえば、特許文献２、特許文献３）。
【０００４】
【特許文献１】特開２００５−３１６６８０号公報
【特許文献２】特開２００６−２５２４２９号公報
【特許文献３】特開２００６−２６８５２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した特許文献１に記載されたようなプロビジョニング技術では、ユーザの要求時に、未使用のシステムリソースを無条件に割り当てているため、そのシステムリソースが故障していた場合、迅速なサービスの提供を行えないという問題点があった。
【０００６】
この問題点の対策としては、未使用のシステムリソースを事前に診断することが考えられるが、上述した特許文献１または２に記載されたような技術では、個々のシステムリソースごとに診断の最適な実施契機を得ることができない問題があった。
【０００７】
本発明の目的は、上述した課題を解決する情報処理装置、判定方法、判定プログラム、およびプロビジョニングシステムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明の第１の情報処理装置は、システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定するリソース管理部と、前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部とを有する。
【０００９】
本発明の第２の情報処理装置は、使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定するリソース管理部と、前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部とを有する。
【００１０】
本発明の第１の判定方法は、コンピュータが、システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、診断対象であると判定された前記システムリソースに診断を実行させる。
【００１１】
本発明の第２の判定方法は、コンピュータが、使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、診断対象であると判定された前記システムリソースに診断を実行させる。
【００１２】
本発明の第１の判定プログラムは、システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、診断対象であると判定された前記システムリソースに診断を実行させる処理をコンピュータに実行させる。
【００１３】
本発明の第２の判定プログラムは、使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる処理をコンピュータに実行させる。
【発明の効果】
【００１４】
本発明によれば、個々のシステムリソースごとに診断の最適な実施契機を得ることが可能になる。
【発明を実施するための最良の形態】
【００１５】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【００１６】
なお、以下の説明において、「単位時間のアクセス数」は一般的に「負荷状況値」と呼ぶことができる。
【００１７】
また、「ＷＥＢアプリケーション」や、「ＤＢ（ＤＡＴＡ ＢＡＳＥ）アプリケーション」は一般的に「アプリケーションプログラム」または「プログラム」と呼ぶことができる。
【００１８】
また、「診断プログラム」は一般的に「プログラム」と呼ぶことができる。
【００１９】
また、ＰＸＥ（Ｐｒｅｂｏｏｔ ｅＸｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）要求はプログラム要求と呼ばれることもある。
【００２０】
また、「診断ＮＢＰ（Ｎｅｔｗｏｒｋ Ｂｏｏｔｓｔｒａｐ Ｐｒｏｇｒａｍ）」や「ＰＸＥ応答」は「診断プログラムを取得するための情報」と呼ばれることもある。
【００２１】
また、「ＷＥＢＮＢＰ」や「ＤＢＮＢＰ」や「ＰＸＥ応答」は「アプリケーションプログラムを取得するための情報」と呼ばれることもある。
【００２２】
また、図面中の『Ｎ／Ａ』は利用不可（ｎｏｔ ａｖａｉｌａｂｌｅ）であることを意味する。
【００２３】
図１を参照すると、本発明の第１の実施の形態は、業務サーバ群１と、管理サーバ２と、ユーザ端末３と、監視端末４と、ファイルサーバ８と、ネットワーク５とを含む。本発明の第１の実施の形態は、以下に説明する構成と動作から、プロビジョニングシステムと呼ぶこともできる。プロビジョニングシステムとは、情報処理または通信の、システムまたは機器等において、ユーザの需要を予想し、サーバやネットワーク設備などの未使用のシステムリソースを事前に用意しておき、ユーザの要求に応じてそれを割り当てて迅速にサービスの提供を行うプロビジョニングの機能を有するシステムである。
【００２４】
業務サーバ群１は、サーバ等の情報処理機器の集まりであり、サーバ１６と、サーバ１７と、サーバ１８と、サーバ１９とを含む。サーバ１６〜１９は、ユーザが要求するサービスに必要なアプリケーションを実行する機能を有する。サーバ１６〜１９は、たとえば、コンピュータ、ネットワーク設備、通信制御装置、周辺装置、その他の情報処理機器であってよい。これらは、一般的にシステムリソースとも呼ばれる。
【００２５】
管理サーバ２は、サービス処理部２２と、診断処理部２３と、リソース管理部２４と、リソース管理データ記憶部２０と、サービス管理データ記憶部２１と、ＮＢＰ記憶部２５とを含む。管理サーバ２は、たとえば、コンピュータ等の情報処理機器であってよい。
【００２６】
リソース管理データ記憶部２０は、業務サーバ群１に含まれるリソースに関する情報を含むリソース管理データ２００を記憶する。リソース管理データ２００は、図５に示すように、リソース識別子２０１、システムリソース名２０２、サービス名２０３、状態２０４、診断日時２０５、診断間隔２０６、最新診断結果２０７、診断フラグ２０８および要求フラグ２０９を含む。
【００２７】
なお、リソース識別子２０１は、システムリソースを一意に決定するシステムリソースの識別子であり、たとえば、システムリソースのＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスであってよい。
【００２８】
システムリソース名２０２は、システムリソースの名称である。
【００２９】
サービス名２０３は、対応するシステムリソースが供されているサービスの名称である。 状態２０４は、システムリソースの使用状況を示し、対応するシステムリソースが、何らかのサービスに供されている（『使用中』）か、否か（『未使用』）を示す情報である。
【００３０】
診断日時２０５は、システムリソースの最近の診断日時であり、対応するシステムリソースの診断が実行された最近の日時である。 診断間隔２０６は、診断間隔時間すなわちシステムリソースの診断を実行すべき間隔の時間であり、対応するシステムリソースが未使用である場合に、診断を実行すべき間隔を示す情報である。たとえば、診断間隔２０６は、『１Ｗ（１Ｗ＝１週間＝１４８時間）』や『２Ｗ』や『３Ｄ（１Ｄ＝１日＝２４時間）』等であってよい。
【００３１】
最新診断結果２０７は、対応するシステムリソースの最近の診断の結果を示す情報である。
【００３２】
診断フラグ２０８は、その値が『１』である場合には、対応するシステムリソースが診断対象の、すなわち診断を実行すべきシステムリソースとして抽出されていることを示す。
【００３３】
要求フラグ２０９は、その値が『１』である場合には、対応するシステムリソースがサービスに追加して供給されるシステムリソースとして抽出されていることを示す情報であり、『１』で有意である。
【００３４】
サービス管理データ記憶部２１は、ユーザに提供されるサービスの名称とＮＢＰのファイル名を関連付けるサービス管理データ２１０を記憶する。サービス管理データ２１０は、図６に示すように、サービス名２０３と、ＮＢＰ名（ＮＢＰのファイル名）２１２とを含む。
図６によると、たとえば、ＷＥＢサーバ機能を提供するＷＥＢサービスのＮＢＰ名２１２は『ＷＥＢＮＢＰ』であり、データ機能を提供するＤＢサービスのＮＢＰ名２１２は『ＤＢＮＢＰ』である。
【００３５】
ＮＢＰ記憶部２５は、診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６およびＤＢＮＢＰ２５７を記憶する。診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６およびＤＢＮＢＰ２５７は、図示しない手段により、あらかじめ、ＮＢＰ記憶部２５に記憶されている（たとえば、管理サーバ２がネットワーク５を経由して図示しない外部記憶装置から取得し、記憶させてもよい）。診断ＮＢＰ２５５は、ファイルサーバ８から診断プログラム１８５をダウンロードして、起動するプログラムである。ＷＥＢＮＢＰ２５６は、ファイルサーバ８からＷＥＢアプリケーション１８６をダウンロードして、起動するプログラムである。ＤＢＮＢＰ２５７は、ファイルサーバ８からＤＢアプリケーション１８７をダウンロードして、起動するプログラムである。
【００３６】
サービス処理部２２は、後述するファイルサーバ８内のＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７の実行を制御する。
【００３７】
サービス処理部２２は、リソース管理部２４から受け取ったサービス開始指示５００（図１２参照）に基づいて、サーバ１６〜１９にＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を実行させる。
【００３８】
以上のサービス処理部２２の動作の詳細は後述する。
【００３９】
診断処理部２３は、診断プログラム１８５の実行を制御する。
【００４０】
診断処理部２３は、リソース管理部２４から受け取った診断実行指示６００（図７参照）に基づいて、サーバ１６〜１９に診断プログラム１８５を実行させる。
【００４１】
以上の、診断処理部２３の動作の詳細は後述する。
【００４２】
リソース管理部２４は、ネットワーク５を介して、業務サーバ群１のサーバ１６〜１９等のシステムリソースを管理する。
【００４３】
リソース管理部２４は、業務サーバ群１に新規にシステムリソースが追加されるとそれを検出し、リソース管理データ２００にその情報を追加する。そして、リソース管理部２４は、診断処理部２３に対してその検出したシステムリソースの診断の実行を指示する。また、リソース管理部２４は、未使用のシステムリソースを検出し、診断処理部２３に対して検出した未使用のシステムリソースの診断の実行を指示する。そして、リソース管理部２４は、診断の実行結果７０１（図８参照）に従って、リソース管理データ２００を更新する。
【００４４】
また、リソース管理部２４は、ユーザ端末３からサービス要求４００を受け取ると、リソース管理データ２００を参照して、最新診断結果２０７が『正常』で、かつ状態２０４が『未使用』であるシステムリソースを検索し、サービス処理部２２にサービスの開始を指示する。
【００４５】
以上のリソース管理部２４の動作の詳細は後述する。
【００４６】
ユーザ端末３は、ネットワーク５を経由してリソース管理部２４にサービスの要求を行う。さらに、ユーザ端末３は、ネットワーク５を経由して、リソース管理データ２００、サービス管理データ２１０を変更する。ユーザ端末３は、たとえば、コンピュータ、その他の情報処理機器であってよい。
【００４７】
以上のユーザ端末３の動作の詳細は後述する。
【００４８】
監視端末４は、ネットワーク５を経由してリソース管理部２４から図８に示す診断プログラム１８５の実行結果７０１を受け取り、診断結果７０３を表示する。監視端末４は、たとえば、コンピュータ、その他の情報処理機器であってよい。
【００４９】
以上の監視端末４の動作の詳細は後述する。
【００５０】
ネットワーク５は、サーバ１６〜１９、管理サーバ２、ユーザ端末３、監視端末４、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ６およびファイルサーバ８を相互に接続する。ネットワーク５は、たとえば、Ethernet（登録商標）や、その他のネットワークであってよい。
【００５１】
ＤＨＣＰサーバ６は、業務サーバ群１のサーバ１６〜１９等のシステムリソースに、管理サーバ２や、ファイルサーバ８等とネットワーク５を介して通信するために必要な情報を通知する。ＤＨＣＰサーバ６の動作の詳細は後述する。
【００５２】
サーバ１６〜１９は、ネットワーク５を介して、ファイルサーバ８に記憶された診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７をダウンロードし、診断プログラム１８５による診断、ＷＥＢアプリケーション１８６によるＷＥＢサービスまたはＤＢアプリケーション１８７によるＤＢサービスを実行する。
【００５３】
以上のサーバ１６〜１９の動作の詳細は後述する。
【００５４】
ファイルサーバ８は、診断プログラム１８５、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７を記憶している。診断プログラム１８５、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７は、図示しない手段により、あらかじめ、ファイルサーバ８に記憶されている。たとえば、ファイルサーバ８が、ネットワーク５を経由して図示しない装置やシステムから診断プログラム１８５、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７を取得し、記憶してもよい。
【００５５】
そして、ファイルサーバ８は、ネットワーク５を介して、サーバ１６〜１９に、診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を送信する。
【００５６】
以上のファイルサーバ８の動作の詳細は後述する。
【００５７】
次に、図１〜図１３を参照して、本発明の第１の実施の形態の動作について、具体的な例を示して詳細に説明する。
【００５８】
まず、本実施の形態で使用するＰＸＥブートについて説明する。ＰＸＥブートは、周知の技術であるため、本実施の形態への適用に関連して明確にする必要のある部分についてのみ説明する。図１０は、本実施の形態におけるサーバ１８、管理サーバ２、ＤＨＣＰサーバ６およびファイルサーバ８によるＰＸＥブートの動作を示すシーケンス図である。
【００５９】
ＰＸＥブートの動作は、サーバ１８の電源が投入されることにより開始される（ステップＳ１）。
【００６０】
まず、サーバ１８は、ネットワーク５を介して、ＤＨＣＰサーバ６にＤＨＣＰ要求を送信する。ＤＨＣＰサーバ６は、このＤＨＣＰ要求を受信する（ステップＳ２）。
【００６１】
そして、ＤＨＣＰサーバ６は、受信したＤＨＣＰ要求に応答して、サーバ１８にＤＨＣＰ応答を、ネットワーク５を介して送信する。サーバ１８は、このＤＨＣＰ応答を受信する（ステップＳ３）。ＤＨＣＰ応答は、少なくとも管理サーバ２のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを含む。
【００６２】
次に、サーバ１８は、ステップＳ３で取得した管理サーバ２のＩＰアドレスを用いて、ネットワーク５を介して、管理サーバ２にＰＸＥ要求を送信する。管理サーバ２は、このＰＸＥ要求を受信する（ステップＳ４）。
【００６３】
そして、管理サーバ２は、受信したＰＸＥ要求に応答して、サーバ１８にＰＸＥ応答を、ネットワーク５を介して送信する。サーバ１８は、このＰＸＥ応答を受信する（ステップＳ５）。ＰＸＥ応答は、少なくとも診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７のファイル名を含む。
【００６４】
次に、サーバ１８は、ステップＳ５で取得した診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７のファイル名を用いて、ネットワーク５を介して、管理サーバ２にＴＦＴＰ（Ｔｒｉｖｉａｌ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）要求を送信する。管理サーバ２は、このＴＦＴＰ要求を受信する（ステップＳ６）。
【００６５】
そして、管理サーバ２は、受信したＴＦＴＰ要求に応答して、サーバ１８に診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７を、ネットワーク５を介して送信する。サーバ１８は、この診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７を受信する（ステップＳ７）。
【００６６】
次に、サーバ１８は、ステップＳ７で受信した診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７を実行する（ステップＳ８）。
【００６７】
すなわち、サーバ１８は、診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７に基づき、ネットワーク５を介して、ファイルサーバ８に、それぞれ診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７のダウンロード要求を送信する。ファイルサーバ８は、このダウンロード要求を受信する（ステップＳ９）。
【００６８】
そして、ファイルサーバ８は、受信したダウンロード要求に応答して、診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を、ネットワーク５を介してサーバ１８に送信する。サーバ１８は、この診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を受信する（ステップＳ１０）。
【００６９】
次に、本実施の形態において、システムリソースを増設した場合の動作について説明する。図２は、システムリソースを増設する動作を示すフローチャートである。以下では、一例として、サーバ１８が増設された場合の動作を説明する。
【００７０】
サーバ１８は、まず管理サーバ２への接続処理を実行する（ステップＡ１０）。この動作は、図１０にステップＳ１からステップＳ４として示される。
【００７１】
次に、リソース管理部２４は、サーバ１８の接続理由を確認する（接続理由？）（ステップＡ１２）。具体的には、リソース管理部２４は、図１０のステップＳ４で受け取ったＰＸＥ要求からＭＡＣアドレスを抽出し、このＭＡＣアドレスをリソース管理データ２００のリソース識別子２０１と順次照合する。そして、リソース管理部２４は、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持するリソース管理データ２００を検出した場合、そのリソース管理データ２００の診断フラグ２０８が有意(『１』)か否かを確認する。そして、リソース管理部２４は、診断フラグ２０８が有意でなければ、さらにリソース管理データ２００の要求フラグ２０９が有意か否かを確認する。
【００７２】
そして、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持し、診断フラグ２０８が有意であるリソース管理データ２００を検出した場合（ステップＡ１２で期間診断対象）、リソース管理部２４は、診断処理部２３に対して図７に示す診断実行指示６００を出力する（ステップＡ１８）。
【００７３】
そして、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持し、要求フラグ２０９が有意であるリソース管理データ２００を検出した場合（ステップＡ１２でサービス要求対象）、リソース管理部２４は、図４のステップＣ２０の処理に移る。
【００７４】
そして、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持するリソース管理データ２００をひとつも検出しなかった場合（ステップＡ１２で増設対象）、リソース管理部２４は、診断処理部２３に対して図７に示す診断実行指示６００を出力する（ステップＡ１８）。
【００７５】
また、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持するリソース管理データ２００を検出したが、この検出したリソース管理データ２００のすべてについて、診断フラグ２０８または要求フラグ２０９のいずれもが有意でなかった場合（ステップＡ１２で無効）、リソース管理部２４は、本処理を終了する（ステップＡ９９）。
【００７６】
なお、この場合、サーバ１８は、図１０のステップＳ５のＰＸＥ応答を受信できない。したがって、サーバ１８は、たとえばＰＸＥ応答の受信タイムアウト処理として、ＰＸＥ応答の待ちを打ち切り、待機状態に移行してもよい（本動作は、図示しない）。
【００７７】
診断実行指示６００を受け取った診断処理部２３は、診断ＮＢＰ２５５をサーバ１８に送信し、サーバ１８は診断ＮＢＰ２５５を実行して、ファイルサーバ８から診断プログラム１８５をダウンロードする（ステップＡ２０）。この動作は、図１０に示すＰＸＥブートの処理のステップＳ５からステップＳ１０の動作と同じである。
【００７８】
そして、サーバ１８は、診断プログラム１８５を起動し、実行する（ステップＡ２２）。
【００７９】
次に、サーバ１８は、診断処理部２３に対し実行結果７０１を送信する（ステップＡ２４）。
【００８０】
さらに、診断処理部２３は、リソース管理部２４および監視端末４に対し、実行結果７０１を送信する（ステップＡ２６）。
【００８１】
そして、リソース管理部２４は、実行結果７０１に基づいてリソース管理データ２００を更新する（ステップＡ３０）。具体的には、診断を実行したシステムリソースのリソース識別子２０１を保持するリソース管理データ２００が既に存在している場合は、リソース管理部２４は、実行結果７０１に基づいて診断日時２０５と最新診断結果２０７とを更新し、診断フラグ２０８を有意でない状態（『０』）にする。また、診断を実行したシステムリソースのリソース識別子２０１を保持するリソース管理データ２００が存在していない場合は、リソース管理部２４は、診断結果に基づいてリソース管理データ２００にサーバ１８のリソース管理データ２００を追加する。このリソース管理データ２００には、サーバ１８のＭＡＣアドレスがリソース識別子２０１として含まれる。また、診断結果が異常であった場合は、リソース管理部２４は、サーバ１８のリソース管理データ２００を追加しないようにしてもよい。
【００８２】
また、監視端末４は、実行結果７０１に基づいて診断結果７０３を表示する（ステップＡ３２）。たとえば、診断結果７０３の表示の例を図９に示す。
【００８３】
こうして、本実施の形態のプロビジョニングシステムは、システムリソースを増設した場合の動作を終了する（ステップＡ９９）。
【００８４】
次に、本実施の形態において、未使用のシステムリソースの診断を実行する場合の動作について説明する。図３は、未使用のシステムリソースの診断を実行する動作を示すフローチャートである。以下では、たとえば、リソース管理データ２００が図５(２)に示す状態で、現在時刻が２００７年１２月２５日１０時００分に達した場合の動作を説明する。なお、現在時刻は、管理サーバ内の図示しない慣用技術の手段により提供される。
【００８５】
リソース管理部２４は、あらかじめ定められた抽出間隔で、リソース管理データ２００を参照し、診断を実行すべきシステムリソースを抽出する（ステップＢ１０）。あらかじめ定められた抽出間隔は、任意の時間であってよい。たとえば、本実施の形態では、あらかじめ定められた抽出間隔は８時間であるとする。リソース管理部２４は、たとえば、管理サーバ２の図示しない計時手段によって、８時間ごとにステップＢ１０を実行する契機を与えられる。そして、リソース管理部２４は、リソース管理データ２００の状態２０４が『未使用』であって、現在時刻とリソース管理データ２００の診断日時２０５との差分が診断間隔２０６を越えているシステムリソースを診断対象のシステムリソースであると判定し、これを抽出する。なお、現在時刻とリソース管理データ２００の診断日時２０５との差分は、すなわち、システムリソースの最近の診断日時からの経過時間である。たとえば、リソース管理部２４は、現在時刻が『２００７年１２月２５日１０時００分』に達したときに、ステップＢ１０を実行する契機を与えられ、ステップＢ１０を実行する。この場合、現在時刻『２００７年１２月２５日１０時００分』とサーバ１９に対応する診断日時２０５『２００７年１２月１８日１０時００分』との時間差が、１週間であるため、リソース管理部２４は、図５(２)のリソース管理データ２００からサーバ１９を診断対象として抽出する。
【００８６】
リソース管理部２４は、診断を実行すべきシステムリソースが抽出されたか否かを確認する（抽出？）（ステップＢ１２）。
【００８７】
そして、診断を実行すべきシステムリソースが抽出されなかった場合（ステップＢ１２でＮＯ）、リソース管理部２４は、本処理を終了する（ステップＢ９９）。
【００８８】
そして、診断を実行すべきシステムリソースが抽出された場合（ステップＢ１２でＹＥＳ）、リソース管理部２４は、診断対象として抽出されたシステムリソース（たとえば、サーバ１９）に対応するリソース管理データ２００の診断フラグ２０８を『１』に設定する（ステップＢ１４）。
【００８９】
そして、リソース管理部２４は、ＷＯＬ（Ｗａｋｅ Ｏｎ ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ））機能により、診断対象として抽出されたシステムリソースの電源を遠隔投入する（ステップＢ１６）。電源の遠隔投入は、たとえば、図示しない手段により図示しない分電盤を制御することにより、電源を供給されたシステムリソースが動作を開始するようにして実現することもできる。
【００９０】
以後は、前述した図２のステップＡ１０以降の処理が実行される。
【００９１】
次に、本実施の形態において、要求されたサービス対して未使用かつ正常なシステムリソースを割り当てる場合の動作について説明する。図４は、要求されるサービスに正常な未使用のシステムリソースを割り当てる動作を示すフローチャートである。
【００９２】
ユーザ端末３は、操作者の指示等により、図１１に示すサービス要求４００を送信する（ステップＣ１０）。
【００９３】
次に、リソース管理部２４は、このサービス要求４００を受信すると、リソース管理データ２００を参照し、割り当て可能なシステムリソースを選択する（リソース有り？）（ステップＣ１２）。なお、割り当て可能なシステムリソースは、対応するリソース管理データ２００の状態２０４が『未使用』で、かつ、最新診断結果２０７が『正常』であるシステムリソースである。選択に当って、リソース管理部２４は、リソース管理データ記憶部２０に記憶されているリソース管理データ２００をアドレス順に確認してシステムリソースを選択してもよいし、診断日時２０５が新しいものあるいは古いものを優先して選択してもよい。
【００９４】
ここでは、リソース管理部２４は、たとえばサーバ１８を選択したものとして説明する。
【００９５】
なお、割り当て可能なシステムリソースを選択できなかった場合（ステップＣ１２でＮＯ）、リソース管理部２４は、ユーザ端末３に対してサービス提供不可を示すサービス応答（図示しない）を通知する（ステップＣ１４）。
【００９６】
割り当て可能なシステムリソースを選択できた場合、すなわち、サーバ１８が選択できた場合（ステップＣ１２でＹＥＳ）、リソース管理部２４は、選択したシステムリソースすなわちサーバ１８に対応するリソース管理データ２００の要求フラグ２０９を『１』に設定する（ステップＣ１６）。
【００９７】
そして、リソース管理部２４は、ＷＯＬ機能により、サーバ１８の電源を遠隔投入する（ステップＣ１８）。
【００９８】
以後は、図２のステップＡ１０以降の処理が実行される。
【００９９】
図２に示すステップＡ１２において、要求フラグ２０９が有意であるリソース管理データ２００を検出した場合（ステップＡ１２でサービス要求対象）（ここでは、サーバ１８に対するデータ２００が検出される）、リソース管理部２４は、サービス処理部２２に対して図１２に示すサービス開始指示５００を出力する（ステップＣ２０）。
【０１００】
次に、サービス処理部２２は、サービス管理データ２１０を参照して、サービス開始指示５００のサービス名２０３『ＷＥＢサービス』に対応するＮＢＰ名２１２『ＷＥＢＮＢＰ』を取得する（ステップＣ２２）。
【０１０１】
そして、サービス処理部２２は、ＮＢＰ名２１２『ＷＥＢＮＢＰ』に対応するＷＥＢＮＢＰ２５６をサーバ１８に送信し、サーバ１８は、受け取ったＷＥＢＮＢＰ２５６を実行して、ファイルサーバ８から対応するＷＥＢアプリケーション１８６をダウンロードする（ステップＣ２４）。この動作は、図１０に、ステップＳ５からステップＳ１０として示される。
【０１０２】
そして、サーバ１８は、ＷＥＢアプリケーション１８６を起動し（ステップＣ２６）、サービス処理部２２に、ＷＥＢアプリケーション１８６の起動の完了を示す情報（図示しない）を送信する（ステップＣ２８）。
【０１０３】
サービス処理部２２は、リソース管理部２４に、ＷＥＢアプリケーション１８６の起動の完了を示す情報を送信する（ステップＣ３０）。
【０１０４】
次に、リソース管理部２４は、リソース管理データ２００を更新する（ステップＣ３２）。具体的には、リソース管理部２４は、サービス名２０３を『ＷＥＢサービス』に、状態２
０４を『使用中』に、要求フラグ２０９を『０』に更新する。
【０１０５】
そして、リソース管理部２４は、ユーザ端末３に対してサービス提供開始を示すサービス応答（図示しない）を通知する（ステップＣ３４）。
【０１０６】
ユーザ端末３は、サービス応答に基づいてサービス要求４００に対する結果を表示する（ステップＣ３６）。
【０１０７】
こうして、本実施の形態のプロビジョニングシステムは、要求されたサービス対して未使用かつ正常なシステムリソースを割り当てる場合の動作を終了する（ステップＣ９９）。
【０１０８】
次に、ユーザ端末３から、サービス管理データ２１０およびリソース管理データ２００を変更する動作について説明する。
【０１０９】
ユーザ端末３は、管理サーバ２に対してサービス名２０３およびＮＢＰ名２１２の組と追加または削除の指示とを含むサービス管理データ変更指示（図示しない）を送信する。管理サーバ２のサービス処理部２２は、受信したサービス管理データ変更指示に基づいてサービス管理データ２１０を変更する。
【０１１０】
また、ユーザ端末３は、管理サーバ２に対してシステムリソース名２０２および診断間隔２０６を含むリソース管理データ変更指示（図示しない）を送信する。管理サーバ２のリソース管理部２４は、受信したリソース管理データ変更指示で指定されたシステムリソース名２０２に対応するリソース管理データ２００の診断間隔２０６を変更する。
【０１１１】
図１３は、本実施の形態の特徴的な構成を示すブロック図である。
【０１１２】
管理サーバ２は、診断処理部２３とリソース管理部２４とを有している。リソース管理部２４は、最近の診断日時からの経過時間すなわち診断日時２０５と現在の時刻との差の時間が診断間隔２０６を越えた場合、このシステムリソースを、診断を実施すべき診断対象のシステムリソースであると判定する。
【０１１３】
そして、診断処理部２３は、リソース管理部２４において診断対象であると判定されたシステムリソースを起動し、診断を実行させる。
【０１１４】
本実施の形態の第１の効果は、ユーザの使用前に問題のある未使用のシステムリソースを発見し対処できる点である。その理由は、あらかじめ定められた診断間隔で未使用のシステムリソースを診断するようにしたからである。
【０１１５】
本実施の形態の第２の効果は、未使用のシステムリソースについて、最適な契機で、診断を実施することが可能になることである。その理由は、リソース識別子と、診断日時と、診断間隔とを参照して診断を実行すべきシステムリソースを抽出し、起動するようにしたからである。
【０１１６】
本実施の形態の第３の効果は、ユーザの要求するサービスに迅速に正常なシステムリソースを提供できる点である。その理由は、診断の結果に問題があると判断された場合に、システムリソースの管理データを更新し、ユーザが要求するサービスに使用しないようにできるためである。
【０１１７】
次に本発明の第２の実施の形態について図面を参照して詳細に説明する。
【０１１８】
本発明の第２の実施の形態は、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７が定期的に統計情報を収集し、リソース管理部２４に送信する機能を有する点と、リソース管理部２４が統計情報に基づいて診断を実行すべきか否かを判定する点とが第１の実施の形態と異なる。統計情報は、システムリソースの負荷情報を示すものであって、たとえば、システムリソースに対する単位時間あたりのアクセス数等がある。
【０１１９】
第２の実施の形態の構成は、第１の実施の形態と同じく図１で示される。また、図２におけるシステムリソースを増設した場合の動作、図４における要求されたサービス対して未使用かつ正常なシステムリソースを割り当てる場合の動作は、第１の実施の形態と同様である。
【０１２０】
図１４は、第２の実施の形態のリソース管理データ記憶部３０およびリソース管理データ３００の構造を示す図である。第２の実施の形態のリソース管理データ３００は、第１の実施の形態のリソース管理データ２００と比べると、診断間隔２０６がなく、単位時間のアクセス数３０１と、閾値３０２とが追加されている。単位時間のアクセス数３０１は、システムリソースが単位時間当たりにアクセスされた回数であり、システムリソースの負荷の状況を示す負荷状況値である。閾値３０２は、単位時間のアクセス数３０１に対する上限値である。
【０１２１】
図１５は、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７が、統計情報を収集し、リソース管理部２４に送信する動作のフローチャートである。
【０１２２】
ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７は、統計情報として単位時間のアクセス数３０１を収集する（ステップＤ１０）。なお、単位時間は、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７それぞれの特性に応じて、たとえば数分であってもよいし、数時間であってもよい。また、アクセス数は、ＷＥＢアプリケーション１８６の場合、読み出されたファイル数を用いてもよく、ＤＢアプリケーション１８７の場合、検索の問い合わせ数を用いてもよい。
【０１２３】
そして、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７は、リソース管理部２４に、単位時間のアクセス数３０１を送信する（ステップＤ１２）。
【０１２４】
次に、リソース管理部２４は、受け取った単位時間のアクセス数３０１に基づいてリソース管理データ３００を更新する（ステップＤ１４）。
【０１２５】
図１６は、リソース管理部２４が統計情報に基づいて診断を実行すべきシステムリソースを抽出する動作のフローチャートである。
【０１２６】
リソース管理部２４は、あらかじめ定められた抽出間隔で、リソース管理データ３００を参照し、単位時間のアクセス数３０１が閾値３０２を越えているシステムリソースが存在するか否かを確認する（閾値３０２を超えているか？）（ステップＥ１２）。なお、あらかじめ定められた抽出間隔は、実施の形態１で説明したものと同じであってよい。たとえば、リソース管理部２４は、図１４に示す値を保持した状態のリソース管理データ３００を参照した場合、サーバ１６の単位時間のアクセス数３０１『２０００』が、閾値３０２『１８００』を越えていることを検出する。
【０１２７】
そして、単位時間のアクセス数３０１が閾値３０２を越えているシステムリソースが存在しなかった場合（ステップＥ１２でＮＯ）、リソース管理部２４は、本処理を終了する（ステップＥ９９）。
【０１２８】
そして、単位時間のアクセス数３０１が閾値３０２を越えているシステムリソースが存在した場合（ステップＥ１２でＹＥＳ）（リソース管理データ３００が図１４に示す値を保持しているならば、サーバ１６が存在する）、リソース管理部２４は、状態２０４が『未使用』のリソース管理データ３００が存在するか否かを確認する（未使用有り？）（ステップＥ１４）。
【０１２９】
そして、状態２０４が『未使用』のリソース管理データ３００が存在しない場合、（ステップＥ１４でＮＯ）、リソース管理部２４は、本処理を終了する（ステップＥ９９）。
【０１３０】
そして、状態２０４が『未使用』のリソース管理データ３００が存在する場合（ステップＥ１４でＹＥＳ）（リソース管理データ３００が図１４に示す値を保持しているならば、サーバ１９およびサーバ１８が存在する）、リソース管理部２４は、対応するシステムリソース（ここでは、サーバ１９およびサーバ１８）を診断すべきシステムリソースとして抽出する（ステップＥ１６）。
【０１３１】
以後の動作は、第１の実施形態で説明した図３のステップＢ１４以降の動作と同じであるため省略する。
【０１３２】
次に、ユーザ端末３からリソース管理データ３００を変更する動作について説明する。
【０１３３】
ユーザ端末３は、管理サーバ２に対してシステムリソース名２０２および閾値３０２を含むリソース管理データ変更指示（図示しない）を送信する。管理サーバ２のリソース管理部２４は、受信したリソース管理データ変更指示で指定されたシステムリソース名２０２に対応するリソース管理データ３００の閾値３０２を変更する。
【０１３４】
本実施の形態は、図１３に示すブロック図の構成においても、その特徴を有している。
【０１３５】
すなわち、リソース管理部２４は、使用中のシステムリソースの負荷状況値すなわち単位時間のアクセス数３０１が閾値３０２を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定する。
【０１３６】
そして、診断処理部２３は、リソース管理部２４において診断対象であると判定されたシステムリソースを起動し、診断を実行させる。
【０１３７】
本実施の形態の効果は、診断回数を適正にできることである。その理由は、診断を実行すべきシステムリソースの抽出ステップを実行するか否かを、使用中のシステムリソースの単位時間のアクセス数と閾値とに基づいて判定するようにしたからである。
【０１３８】
以上の実施の形態で説明した各構成要素は、たとえば、プログラムにより所定の処理をコンピュータに実行させてもよい。
【０１３９】
また、以上の実施の形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はなく、複数の構成要素が一個のモジュールとして実現されていること、ひとつの構成要素が複数のモジュールで実現されていること、ある構成要素が他の構成要素の一部であること、ある構成要素の一部と他の構成要素の一部とが重複していること、等でもよい。
【０１４０】
また、以上説明した、実施の形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、本実施の形態を実施するときには、その複数の動作の順番は内容的に支障しない範囲で変更することができる。
【０１４１】
さらに、以上説明した、実施の形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。このため、ある動作の実行中に他の動作が発生すること、ある動作の実行タイミングと他の動作の実行タイミングとの一部ないし全部が重複していること、等でもよい。
【０１４２】
さらに、以上説明した、実施の形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作のすべての関係を限定するものではない。このため、本実施の形態を実施するときには、その複数の動作の関係は内容的に支障しない範囲で変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、本実施の形態を実施する上で機能的、性能的、その他の特性に対して支障をきたさない範囲内で変更されて良い。
【０１４３】
なお、以上説明した、実施の形態は、ハードウェアで実現されても良いし、ソフトウェアで実現されても良いし、ハードウェアとソフトウェアの混在により実現されても良い。
【０１４４】
また、各構成要素の物理的な構成は、以上の実施の形態の記載に限定されることはなく、独立して存在しても良いし、組み合わされて存在しても良いしまたは分離して構成されても良い。
【産業上の利用可能性】
【０１４５】
本発明は、プロビジョニングシステム等のシステムリソース管理に適用できる。
【図面の簡単な説明】
【０１４６】
【図１】本発明の第１および第２の実施の形態の構成を示すブロック図である。
【図２】本発明の第１および第２の実施の形態におけるシステムリソースを増設する動作を示すフローチャートである。
【図３】本発明の第１および第２の実施の形態における未使用のシステムリソースの診断を実行する動作を示すフローチャート
【図４】本発明の第１および第２の実施の形態における要求されるサービスに正常な未使用のシステムリソースを割り当てる動作を示すフローチャートである。
【図５】本発明の第１の実施の形態におけるリソース管理データ記憶部と、リソース管理データとの構造を示す図である。
【図６】本発明の第１および第２の実施の形態におけるサービス管理データ記憶部と、サービス管理データとの構造を示す図である。
【図７】本発明の第１および第２の実施の形態における診断実行指示の構造を示す図である。
【図８】本発明の第１および第２の実施の形態における診断プログラムの実行結果の構造を示す図である。
【図９】本発明の第１および第２の実施の形態における診断結果の構造を示す図である。
【図１０】本発明の第１および第２の実施の形態におけるＰＸＥブートの動作を示すシーケンス図である。
【図１１】本発明の第１および第２の実施の形態におけるサービス要求の構造を示す図である。
【図１２】本発明の第１および第２の実施の形態におけるサービス開始指示の構造を示す図である。
【図１３】本発明の第１および第２の実施の形態における特徴的な構成を示すブロック図である。
【図１４】本発明の第２の実施の形態におけるサービス管理データ記憶部と、サービス管理データとの構造を示す図である。
【図１５】本発明の第２の実施の形態におけるアプリケーションが統計情報を収集しリソース管理部に送信する動作のフローチャートである。
【図１６】本発明の第２の実施の形態におけるリソース管理部が統計情報に基づいて診断を実行すべきシステムリソースを抽出する動作のフローチャートである。
【符号の説明】
【０１４７】
１ 業務サーバ群
１６ サーバ
１６〜１９ サーバ
１７ サーバ
１８ サーバ
１８５ 診断プログラム
１８６ ＷＥＢアプリケーション
１８７ ＤＢアプリケーション
１９ サーバ
２ 管理サーバ
２０ リソース管理データ記憶部
２００ リソース管理データ
２０１ リソース識別子
２０２ システムリソース名
２０３ サービス名
２０４ 状態
２０５ 診断日時
２０６ 診断間隔
２０７ 最新診断結果
２０８ 診断フラグ
２０９ 要求フラグ
２１ サービス管理データ記憶部
２１０ サービス管理データ
２１２ ＮＢＰ名
２２ サービス処理部
２３ 診断処理部
２４ リソース管理部
２５ ＮＢＰ記憶部
２５５ 診断ＮＢＰ
２５６ ＷＥＢＮＢＰ
２５７ ＤＢＮＢＰ
３ ユーザ端末
３０ リソース管理データ記憶部
３００ リソース管理データ
３０１ 単位時間のアクセス数
３０２ 閾値
４ 監視端末
４００ サービス要求
５ ネットワーク
５００ サービス開始指示
６ ＤＨＣＰサーバ
６００ 診断実行指示
７０１ 実行結果
７０３ 診断結果
８ ファイルサーバ
【技術分野】
【０００１】
本発明は情報処理装置、判定方法、判定プログラム、およびプロビジョニングシステムに関し、特に、予防診断を制御する情報処理装置、判定方法、判定プログラム、およびプロビジョニングシステムに関する。
【背景技術】
【０００２】
情報／通信のシステム、機器等においては、ユーザの需要を予想し、サーバやネットワーク設備などの未使用のシステムリソースを事前に用意しておき、ユーザの要求に応じてそれを割り当てて迅速にサービスの提供を行うプロビジョニング技術がある（たとえば、特許文献１）。
【０００３】
また、コンピュータシステムにおいて、予備プロセッサや予備ＣＥＬＬ等のシステムリソースを定期的に診断する技術がある（たとえば、特許文献２、特許文献３）。
【０００４】
【特許文献１】特開２００５−３１６６８０号公報
【特許文献２】特開２００６−２５２４２９号公報
【特許文献３】特開２００６−２６８５２１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した特許文献１に記載されたようなプロビジョニング技術では、ユーザの要求時に、未使用のシステムリソースを無条件に割り当てているため、そのシステムリソースが故障していた場合、迅速なサービスの提供を行えないという問題点があった。
【０００６】
この問題点の対策としては、未使用のシステムリソースを事前に診断することが考えられるが、上述した特許文献１または２に記載されたような技術では、個々のシステムリソースごとに診断の最適な実施契機を得ることができない問題があった。
【０００７】
本発明の目的は、上述した課題を解決する情報処理装置、判定方法、判定プログラム、およびプロビジョニングシステムを提供することにある。
【課題を解決するための手段】
【０００８】
本発明の第１の情報処理装置は、システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定するリソース管理部と、前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部とを有する。
【０００９】
本発明の第２の情報処理装置は、使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定するリソース管理部と、前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部とを有する。
【００１０】
本発明の第１の判定方法は、コンピュータが、システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、診断対象であると判定された前記システムリソースに診断を実行させる。
【００１１】
本発明の第２の判定方法は、コンピュータが、使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、診断対象であると判定された前記システムリソースに診断を実行させる。
【００１２】
本発明の第１の判定プログラムは、システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、診断対象であると判定された前記システムリソースに診断を実行させる処理をコンピュータに実行させる。
【００１３】
本発明の第２の判定プログラムは、使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる処理をコンピュータに実行させる。
【発明の効果】
【００１４】
本発明によれば、個々のシステムリソースごとに診断の最適な実施契機を得ることが可能になる。
【発明を実施するための最良の形態】
【００１５】
次に、本発明の実施の形態について図面を参照して詳細に説明する。
【００１６】
なお、以下の説明において、「単位時間のアクセス数」は一般的に「負荷状況値」と呼ぶことができる。
【００１７】
また、「ＷＥＢアプリケーション」や、「ＤＢ（ＤＡＴＡ ＢＡＳＥ）アプリケーション」は一般的に「アプリケーションプログラム」または「プログラム」と呼ぶことができる。
【００１８】
また、「診断プログラム」は一般的に「プログラム」と呼ぶことができる。
【００１９】
また、ＰＸＥ（Ｐｒｅｂｏｏｔ ｅＸｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）要求はプログラム要求と呼ばれることもある。
【００２０】
また、「診断ＮＢＰ（Ｎｅｔｗｏｒｋ Ｂｏｏｔｓｔｒａｐ Ｐｒｏｇｒａｍ）」や「ＰＸＥ応答」は「診断プログラムを取得するための情報」と呼ばれることもある。
【００２１】
また、「ＷＥＢＮＢＰ」や「ＤＢＮＢＰ」や「ＰＸＥ応答」は「アプリケーションプログラムを取得するための情報」と呼ばれることもある。
【００２２】
また、図面中の『Ｎ／Ａ』は利用不可（ｎｏｔ ａｖａｉｌａｂｌｅ）であることを意味する。
【００２３】
図１を参照すると、本発明の第１の実施の形態は、業務サーバ群１と、管理サーバ２と、ユーザ端末３と、監視端末４と、ファイルサーバ８と、ネットワーク５とを含む。本発明の第１の実施の形態は、以下に説明する構成と動作から、プロビジョニングシステムと呼ぶこともできる。プロビジョニングシステムとは、情報処理または通信の、システムまたは機器等において、ユーザの需要を予想し、サーバやネットワーク設備などの未使用のシステムリソースを事前に用意しておき、ユーザの要求に応じてそれを割り当てて迅速にサービスの提供を行うプロビジョニングの機能を有するシステムである。
【００２４】
業務サーバ群１は、サーバ等の情報処理機器の集まりであり、サーバ１６と、サーバ１７と、サーバ１８と、サーバ１９とを含む。サーバ１６〜１９は、ユーザが要求するサービスに必要なアプリケーションを実行する機能を有する。サーバ１６〜１９は、たとえば、コンピュータ、ネットワーク設備、通信制御装置、周辺装置、その他の情報処理機器であってよい。これらは、一般的にシステムリソースとも呼ばれる。
【００２５】
管理サーバ２は、サービス処理部２２と、診断処理部２３と、リソース管理部２４と、リソース管理データ記憶部２０と、サービス管理データ記憶部２１と、ＮＢＰ記憶部２５とを含む。管理サーバ２は、たとえば、コンピュータ等の情報処理機器であってよい。
【００２６】
リソース管理データ記憶部２０は、業務サーバ群１に含まれるリソースに関する情報を含むリソース管理データ２００を記憶する。リソース管理データ２００は、図５に示すように、リソース識別子２０１、システムリソース名２０２、サービス名２０３、状態２０４、診断日時２０５、診断間隔２０６、最新診断結果２０７、診断フラグ２０８および要求フラグ２０９を含む。
【００２７】
なお、リソース識別子２０１は、システムリソースを一意に決定するシステムリソースの識別子であり、たとえば、システムリソースのＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）アドレスであってよい。
【００２８】
システムリソース名２０２は、システムリソースの名称である。
【００２９】
サービス名２０３は、対応するシステムリソースが供されているサービスの名称である。 状態２０４は、システムリソースの使用状況を示し、対応するシステムリソースが、何らかのサービスに供されている（『使用中』）か、否か（『未使用』）を示す情報である。
【００３０】
診断日時２０５は、システムリソースの最近の診断日時であり、対応するシステムリソースの診断が実行された最近の日時である。 診断間隔２０６は、診断間隔時間すなわちシステムリソースの診断を実行すべき間隔の時間であり、対応するシステムリソースが未使用である場合に、診断を実行すべき間隔を示す情報である。たとえば、診断間隔２０６は、『１Ｗ（１Ｗ＝１週間＝１４８時間）』や『２Ｗ』や『３Ｄ（１Ｄ＝１日＝２４時間）』等であってよい。
【００３１】
最新診断結果２０７は、対応するシステムリソースの最近の診断の結果を示す情報である。
【００３２】
診断フラグ２０８は、その値が『１』である場合には、対応するシステムリソースが診断対象の、すなわち診断を実行すべきシステムリソースとして抽出されていることを示す。
【００３３】
要求フラグ２０９は、その値が『１』である場合には、対応するシステムリソースがサービスに追加して供給されるシステムリソースとして抽出されていることを示す情報であり、『１』で有意である。
【００３４】
サービス管理データ記憶部２１は、ユーザに提供されるサービスの名称とＮＢＰのファイル名を関連付けるサービス管理データ２１０を記憶する。サービス管理データ２１０は、図６に示すように、サービス名２０３と、ＮＢＰ名（ＮＢＰのファイル名）２１２とを含む。
図６によると、たとえば、ＷＥＢサーバ機能を提供するＷＥＢサービスのＮＢＰ名２１２は『ＷＥＢＮＢＰ』であり、データ機能を提供するＤＢサービスのＮＢＰ名２１２は『ＤＢＮＢＰ』である。
【００３５】
ＮＢＰ記憶部２５は、診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６およびＤＢＮＢＰ２５７を記憶する。診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６およびＤＢＮＢＰ２５７は、図示しない手段により、あらかじめ、ＮＢＰ記憶部２５に記憶されている（たとえば、管理サーバ２がネットワーク５を経由して図示しない外部記憶装置から取得し、記憶させてもよい）。診断ＮＢＰ２５５は、ファイルサーバ８から診断プログラム１８５をダウンロードして、起動するプログラムである。ＷＥＢＮＢＰ２５６は、ファイルサーバ８からＷＥＢアプリケーション１８６をダウンロードして、起動するプログラムである。ＤＢＮＢＰ２５７は、ファイルサーバ８からＤＢアプリケーション１８７をダウンロードして、起動するプログラムである。
【００３６】
サービス処理部２２は、後述するファイルサーバ８内のＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７の実行を制御する。
【００３７】
サービス処理部２２は、リソース管理部２４から受け取ったサービス開始指示５００（図１２参照）に基づいて、サーバ１６〜１９にＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を実行させる。
【００３８】
以上のサービス処理部２２の動作の詳細は後述する。
【００３９】
診断処理部２３は、診断プログラム１８５の実行を制御する。
【００４０】
診断処理部２３は、リソース管理部２４から受け取った診断実行指示６００（図７参照）に基づいて、サーバ１６〜１９に診断プログラム１８５を実行させる。
【００４１】
以上の、診断処理部２３の動作の詳細は後述する。
【００４２】
リソース管理部２４は、ネットワーク５を介して、業務サーバ群１のサーバ１６〜１９等のシステムリソースを管理する。
【００４３】
リソース管理部２４は、業務サーバ群１に新規にシステムリソースが追加されるとそれを検出し、リソース管理データ２００にその情報を追加する。そして、リソース管理部２４は、診断処理部２３に対してその検出したシステムリソースの診断の実行を指示する。また、リソース管理部２４は、未使用のシステムリソースを検出し、診断処理部２３に対して検出した未使用のシステムリソースの診断の実行を指示する。そして、リソース管理部２４は、診断の実行結果７０１（図８参照）に従って、リソース管理データ２００を更新する。
【００４４】
また、リソース管理部２４は、ユーザ端末３からサービス要求４００を受け取ると、リソース管理データ２００を参照して、最新診断結果２０７が『正常』で、かつ状態２０４が『未使用』であるシステムリソースを検索し、サービス処理部２２にサービスの開始を指示する。
【００４５】
以上のリソース管理部２４の動作の詳細は後述する。
【００４６】
ユーザ端末３は、ネットワーク５を経由してリソース管理部２４にサービスの要求を行う。さらに、ユーザ端末３は、ネットワーク５を経由して、リソース管理データ２００、サービス管理データ２１０を変更する。ユーザ端末３は、たとえば、コンピュータ、その他の情報処理機器であってよい。
【００４７】
以上のユーザ端末３の動作の詳細は後述する。
【００４８】
監視端末４は、ネットワーク５を経由してリソース管理部２４から図８に示す診断プログラム１８５の実行結果７０１を受け取り、診断結果７０３を表示する。監視端末４は、たとえば、コンピュータ、その他の情報処理機器であってよい。
【００４９】
以上の監視端末４の動作の詳細は後述する。
【００５０】
ネットワーク５は、サーバ１６〜１９、管理サーバ２、ユーザ端末３、監視端末４、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）サーバ６およびファイルサーバ８を相互に接続する。ネットワーク５は、たとえば、Ethernet（登録商標）や、その他のネットワークであってよい。
【００５１】
ＤＨＣＰサーバ６は、業務サーバ群１のサーバ１６〜１９等のシステムリソースに、管理サーバ２や、ファイルサーバ８等とネットワーク５を介して通信するために必要な情報を通知する。ＤＨＣＰサーバ６の動作の詳細は後述する。
【００５２】
サーバ１６〜１９は、ネットワーク５を介して、ファイルサーバ８に記憶された診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７をダウンロードし、診断プログラム１８５による診断、ＷＥＢアプリケーション１８６によるＷＥＢサービスまたはＤＢアプリケーション１８７によるＤＢサービスを実行する。
【００５３】
以上のサーバ１６〜１９の動作の詳細は後述する。
【００５４】
ファイルサーバ８は、診断プログラム１８５、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７を記憶している。診断プログラム１８５、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７は、図示しない手段により、あらかじめ、ファイルサーバ８に記憶されている。たとえば、ファイルサーバ８が、ネットワーク５を経由して図示しない装置やシステムから診断プログラム１８５、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７を取得し、記憶してもよい。
【００５５】
そして、ファイルサーバ８は、ネットワーク５を介して、サーバ１６〜１９に、診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を送信する。
【００５６】
以上のファイルサーバ８の動作の詳細は後述する。
【００５７】
次に、図１〜図１３を参照して、本発明の第１の実施の形態の動作について、具体的な例を示して詳細に説明する。
【００５８】
まず、本実施の形態で使用するＰＸＥブートについて説明する。ＰＸＥブートは、周知の技術であるため、本実施の形態への適用に関連して明確にする必要のある部分についてのみ説明する。図１０は、本実施の形態におけるサーバ１８、管理サーバ２、ＤＨＣＰサーバ６およびファイルサーバ８によるＰＸＥブートの動作を示すシーケンス図である。
【００５９】
ＰＸＥブートの動作は、サーバ１８の電源が投入されることにより開始される（ステップＳ１）。
【００６０】
まず、サーバ１８は、ネットワーク５を介して、ＤＨＣＰサーバ６にＤＨＣＰ要求を送信する。ＤＨＣＰサーバ６は、このＤＨＣＰ要求を受信する（ステップＳ２）。
【００６１】
そして、ＤＨＣＰサーバ６は、受信したＤＨＣＰ要求に応答して、サーバ１８にＤＨＣＰ応答を、ネットワーク５を介して送信する。サーバ１８は、このＤＨＣＰ応答を受信する（ステップＳ３）。ＤＨＣＰ応答は、少なくとも管理サーバ２のＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスを含む。
【００６２】
次に、サーバ１８は、ステップＳ３で取得した管理サーバ２のＩＰアドレスを用いて、ネットワーク５を介して、管理サーバ２にＰＸＥ要求を送信する。管理サーバ２は、このＰＸＥ要求を受信する（ステップＳ４）。
【００６３】
そして、管理サーバ２は、受信したＰＸＥ要求に応答して、サーバ１８にＰＸＥ応答を、ネットワーク５を介して送信する。サーバ１８は、このＰＸＥ応答を受信する（ステップＳ５）。ＰＸＥ応答は、少なくとも診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７のファイル名を含む。
【００６４】
次に、サーバ１８は、ステップＳ５で取得した診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７のファイル名を用いて、ネットワーク５を介して、管理サーバ２にＴＦＴＰ（Ｔｒｉｖｉａｌ Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）要求を送信する。管理サーバ２は、このＴＦＴＰ要求を受信する（ステップＳ６）。
【００６５】
そして、管理サーバ２は、受信したＴＦＴＰ要求に応答して、サーバ１８に診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７を、ネットワーク５を介して送信する。サーバ１８は、この診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７を受信する（ステップＳ７）。
【００６６】
次に、サーバ１８は、ステップＳ７で受信した診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７を実行する（ステップＳ８）。
【００６７】
すなわち、サーバ１８は、診断ＮＢＰ２５５、ＷＥＢＮＢＰ２５６またはＤＢＮＢＰ２５７に基づき、ネットワーク５を介して、ファイルサーバ８に、それぞれ診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７のダウンロード要求を送信する。ファイルサーバ８は、このダウンロード要求を受信する（ステップＳ９）。
【００６８】
そして、ファイルサーバ８は、受信したダウンロード要求に応答して、診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を、ネットワーク５を介してサーバ１８に送信する。サーバ１８は、この診断プログラム１８５、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７を受信する（ステップＳ１０）。
【００６９】
次に、本実施の形態において、システムリソースを増設した場合の動作について説明する。図２は、システムリソースを増設する動作を示すフローチャートである。以下では、一例として、サーバ１８が増設された場合の動作を説明する。
【００７０】
サーバ１８は、まず管理サーバ２への接続処理を実行する（ステップＡ１０）。この動作は、図１０にステップＳ１からステップＳ４として示される。
【００７１】
次に、リソース管理部２４は、サーバ１８の接続理由を確認する（接続理由？）（ステップＡ１２）。具体的には、リソース管理部２４は、図１０のステップＳ４で受け取ったＰＸＥ要求からＭＡＣアドレスを抽出し、このＭＡＣアドレスをリソース管理データ２００のリソース識別子２０１と順次照合する。そして、リソース管理部２４は、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持するリソース管理データ２００を検出した場合、そのリソース管理データ２００の診断フラグ２０８が有意(『１』)か否かを確認する。そして、リソース管理部２４は、診断フラグ２０８が有意でなければ、さらにリソース管理データ２００の要求フラグ２０９が有意か否かを確認する。
【００７２】
そして、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持し、診断フラグ２０８が有意であるリソース管理データ２００を検出した場合（ステップＡ１２で期間診断対象）、リソース管理部２４は、診断処理部２３に対して図７に示す診断実行指示６００を出力する（ステップＡ１８）。
【００７３】
そして、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持し、要求フラグ２０９が有意であるリソース管理データ２００を検出した場合（ステップＡ１２でサービス要求対象）、リソース管理部２４は、図４のステップＣ２０の処理に移る。
【００７４】
そして、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持するリソース管理データ２００をひとつも検出しなかった場合（ステップＡ１２で増設対象）、リソース管理部２４は、診断処理部２３に対して図７に示す診断実行指示６００を出力する（ステップＡ１８）。
【００７５】
また、抽出したＭＡＣアドレスと一致するリソース識別子２０１を保持するリソース管理データ２００を検出したが、この検出したリソース管理データ２００のすべてについて、診断フラグ２０８または要求フラグ２０９のいずれもが有意でなかった場合（ステップＡ１２で無効）、リソース管理部２４は、本処理を終了する（ステップＡ９９）。
【００７６】
なお、この場合、サーバ１８は、図１０のステップＳ５のＰＸＥ応答を受信できない。したがって、サーバ１８は、たとえばＰＸＥ応答の受信タイムアウト処理として、ＰＸＥ応答の待ちを打ち切り、待機状態に移行してもよい（本動作は、図示しない）。
【００７７】
診断実行指示６００を受け取った診断処理部２３は、診断ＮＢＰ２５５をサーバ１８に送信し、サーバ１８は診断ＮＢＰ２５５を実行して、ファイルサーバ８から診断プログラム１８５をダウンロードする（ステップＡ２０）。この動作は、図１０に示すＰＸＥブートの処理のステップＳ５からステップＳ１０の動作と同じである。
【００７８】
そして、サーバ１８は、診断プログラム１８５を起動し、実行する（ステップＡ２２）。
【００７９】
次に、サーバ１８は、診断処理部２３に対し実行結果７０１を送信する（ステップＡ２４）。
【００８０】
さらに、診断処理部２３は、リソース管理部２４および監視端末４に対し、実行結果７０１を送信する（ステップＡ２６）。
【００８１】
そして、リソース管理部２４は、実行結果７０１に基づいてリソース管理データ２００を更新する（ステップＡ３０）。具体的には、診断を実行したシステムリソースのリソース識別子２０１を保持するリソース管理データ２００が既に存在している場合は、リソース管理部２４は、実行結果７０１に基づいて診断日時２０５と最新診断結果２０７とを更新し、診断フラグ２０８を有意でない状態（『０』）にする。また、診断を実行したシステムリソースのリソース識別子２０１を保持するリソース管理データ２００が存在していない場合は、リソース管理部２４は、診断結果に基づいてリソース管理データ２００にサーバ１８のリソース管理データ２００を追加する。このリソース管理データ２００には、サーバ１８のＭＡＣアドレスがリソース識別子２０１として含まれる。また、診断結果が異常であった場合は、リソース管理部２４は、サーバ１８のリソース管理データ２００を追加しないようにしてもよい。
【００８２】
また、監視端末４は、実行結果７０１に基づいて診断結果７０３を表示する（ステップＡ３２）。たとえば、診断結果７０３の表示の例を図９に示す。
【００８３】
こうして、本実施の形態のプロビジョニングシステムは、システムリソースを増設した場合の動作を終了する（ステップＡ９９）。
【００８４】
次に、本実施の形態において、未使用のシステムリソースの診断を実行する場合の動作について説明する。図３は、未使用のシステムリソースの診断を実行する動作を示すフローチャートである。以下では、たとえば、リソース管理データ２００が図５(２)に示す状態で、現在時刻が２００７年１２月２５日１０時００分に達した場合の動作を説明する。なお、現在時刻は、管理サーバ内の図示しない慣用技術の手段により提供される。
【００８５】
リソース管理部２４は、あらかじめ定められた抽出間隔で、リソース管理データ２００を参照し、診断を実行すべきシステムリソースを抽出する（ステップＢ１０）。あらかじめ定められた抽出間隔は、任意の時間であってよい。たとえば、本実施の形態では、あらかじめ定められた抽出間隔は８時間であるとする。リソース管理部２４は、たとえば、管理サーバ２の図示しない計時手段によって、８時間ごとにステップＢ１０を実行する契機を与えられる。そして、リソース管理部２４は、リソース管理データ２００の状態２０４が『未使用』であって、現在時刻とリソース管理データ２００の診断日時２０５との差分が診断間隔２０６を越えているシステムリソースを診断対象のシステムリソースであると判定し、これを抽出する。なお、現在時刻とリソース管理データ２００の診断日時２０５との差分は、すなわち、システムリソースの最近の診断日時からの経過時間である。たとえば、リソース管理部２４は、現在時刻が『２００７年１２月２５日１０時００分』に達したときに、ステップＢ１０を実行する契機を与えられ、ステップＢ１０を実行する。この場合、現在時刻『２００７年１２月２５日１０時００分』とサーバ１９に対応する診断日時２０５『２００７年１２月１８日１０時００分』との時間差が、１週間であるため、リソース管理部２４は、図５(２)のリソース管理データ２００からサーバ１９を診断対象として抽出する。
【００８６】
リソース管理部２４は、診断を実行すべきシステムリソースが抽出されたか否かを確認する（抽出？）（ステップＢ１２）。
【００８７】
そして、診断を実行すべきシステムリソースが抽出されなかった場合（ステップＢ１２でＮＯ）、リソース管理部２４は、本処理を終了する（ステップＢ９９）。
【００８８】
そして、診断を実行すべきシステムリソースが抽出された場合（ステップＢ１２でＹＥＳ）、リソース管理部２４は、診断対象として抽出されたシステムリソース（たとえば、サーバ１９）に対応するリソース管理データ２００の診断フラグ２０８を『１』に設定する（ステップＢ１４）。
【００８９】
そして、リソース管理部２４は、ＷＯＬ（Ｗａｋｅ Ｏｎ ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ））機能により、診断対象として抽出されたシステムリソースの電源を遠隔投入する（ステップＢ１６）。電源の遠隔投入は、たとえば、図示しない手段により図示しない分電盤を制御することにより、電源を供給されたシステムリソースが動作を開始するようにして実現することもできる。
【００９０】
以後は、前述した図２のステップＡ１０以降の処理が実行される。
【００９１】
次に、本実施の形態において、要求されたサービス対して未使用かつ正常なシステムリソースを割り当てる場合の動作について説明する。図４は、要求されるサービスに正常な未使用のシステムリソースを割り当てる動作を示すフローチャートである。
【００９２】
ユーザ端末３は、操作者の指示等により、図１１に示すサービス要求４００を送信する（ステップＣ１０）。
【００９３】
次に、リソース管理部２４は、このサービス要求４００を受信すると、リソース管理データ２００を参照し、割り当て可能なシステムリソースを選択する（リソース有り？）（ステップＣ１２）。なお、割り当て可能なシステムリソースは、対応するリソース管理データ２００の状態２０４が『未使用』で、かつ、最新診断結果２０７が『正常』であるシステムリソースである。選択に当って、リソース管理部２４は、リソース管理データ記憶部２０に記憶されているリソース管理データ２００をアドレス順に確認してシステムリソースを選択してもよいし、診断日時２０５が新しいものあるいは古いものを優先して選択してもよい。
【００９４】
ここでは、リソース管理部２４は、たとえばサーバ１８を選択したものとして説明する。
【００９５】
なお、割り当て可能なシステムリソースを選択できなかった場合（ステップＣ１２でＮＯ）、リソース管理部２４は、ユーザ端末３に対してサービス提供不可を示すサービス応答（図示しない）を通知する（ステップＣ１４）。
【００９６】
割り当て可能なシステムリソースを選択できた場合、すなわち、サーバ１８が選択できた場合（ステップＣ１２でＹＥＳ）、リソース管理部２４は、選択したシステムリソースすなわちサーバ１８に対応するリソース管理データ２００の要求フラグ２０９を『１』に設定する（ステップＣ１６）。
【００９７】
そして、リソース管理部２４は、ＷＯＬ機能により、サーバ１８の電源を遠隔投入する（ステップＣ１８）。
【００９８】
以後は、図２のステップＡ１０以降の処理が実行される。
【００９９】
図２に示すステップＡ１２において、要求フラグ２０９が有意であるリソース管理データ２００を検出した場合（ステップＡ１２でサービス要求対象）（ここでは、サーバ１８に対するデータ２００が検出される）、リソース管理部２４は、サービス処理部２２に対して図１２に示すサービス開始指示５００を出力する（ステップＣ２０）。
【０１００】
次に、サービス処理部２２は、サービス管理データ２１０を参照して、サービス開始指示５００のサービス名２０３『ＷＥＢサービス』に対応するＮＢＰ名２１２『ＷＥＢＮＢＰ』を取得する（ステップＣ２２）。
【０１０１】
そして、サービス処理部２２は、ＮＢＰ名２１２『ＷＥＢＮＢＰ』に対応するＷＥＢＮＢＰ２５６をサーバ１８に送信し、サーバ１８は、受け取ったＷＥＢＮＢＰ２５６を実行して、ファイルサーバ８から対応するＷＥＢアプリケーション１８６をダウンロードする（ステップＣ２４）。この動作は、図１０に、ステップＳ５からステップＳ１０として示される。
【０１０２】
そして、サーバ１８は、ＷＥＢアプリケーション１８６を起動し（ステップＣ２６）、サービス処理部２２に、ＷＥＢアプリケーション１８６の起動の完了を示す情報（図示しない）を送信する（ステップＣ２８）。
【０１０３】
サービス処理部２２は、リソース管理部２４に、ＷＥＢアプリケーション１８６の起動の完了を示す情報を送信する（ステップＣ３０）。
【０１０４】
次に、リソース管理部２４は、リソース管理データ２００を更新する（ステップＣ３２）。具体的には、リソース管理部２４は、サービス名２０３を『ＷＥＢサービス』に、状態２
０４を『使用中』に、要求フラグ２０９を『０』に更新する。
【０１０５】
そして、リソース管理部２４は、ユーザ端末３に対してサービス提供開始を示すサービス応答（図示しない）を通知する（ステップＣ３４）。
【０１０６】
ユーザ端末３は、サービス応答に基づいてサービス要求４００に対する結果を表示する（ステップＣ３６）。
【０１０７】
こうして、本実施の形態のプロビジョニングシステムは、要求されたサービス対して未使用かつ正常なシステムリソースを割り当てる場合の動作を終了する（ステップＣ９９）。
【０１０８】
次に、ユーザ端末３から、サービス管理データ２１０およびリソース管理データ２００を変更する動作について説明する。
【０１０９】
ユーザ端末３は、管理サーバ２に対してサービス名２０３およびＮＢＰ名２１２の組と追加または削除の指示とを含むサービス管理データ変更指示（図示しない）を送信する。管理サーバ２のサービス処理部２２は、受信したサービス管理データ変更指示に基づいてサービス管理データ２１０を変更する。
【０１１０】
また、ユーザ端末３は、管理サーバ２に対してシステムリソース名２０２および診断間隔２０６を含むリソース管理データ変更指示（図示しない）を送信する。管理サーバ２のリソース管理部２４は、受信したリソース管理データ変更指示で指定されたシステムリソース名２０２に対応するリソース管理データ２００の診断間隔２０６を変更する。
【０１１１】
図１３は、本実施の形態の特徴的な構成を示すブロック図である。
【０１１２】
管理サーバ２は、診断処理部２３とリソース管理部２４とを有している。リソース管理部２４は、最近の診断日時からの経過時間すなわち診断日時２０５と現在の時刻との差の時間が診断間隔２０６を越えた場合、このシステムリソースを、診断を実施すべき診断対象のシステムリソースであると判定する。
【０１１３】
そして、診断処理部２３は、リソース管理部２４において診断対象であると判定されたシステムリソースを起動し、診断を実行させる。
【０１１４】
本実施の形態の第１の効果は、ユーザの使用前に問題のある未使用のシステムリソースを発見し対処できる点である。その理由は、あらかじめ定められた診断間隔で未使用のシステムリソースを診断するようにしたからである。
【０１１５】
本実施の形態の第２の効果は、未使用のシステムリソースについて、最適な契機で、診断を実施することが可能になることである。その理由は、リソース識別子と、診断日時と、診断間隔とを参照して診断を実行すべきシステムリソースを抽出し、起動するようにしたからである。
【０１１６】
本実施の形態の第３の効果は、ユーザの要求するサービスに迅速に正常なシステムリソースを提供できる点である。その理由は、診断の結果に問題があると判断された場合に、システムリソースの管理データを更新し、ユーザが要求するサービスに使用しないようにできるためである。
【０１１７】
次に本発明の第２の実施の形態について図面を参照して詳細に説明する。
【０１１８】
本発明の第２の実施の形態は、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７が定期的に統計情報を収集し、リソース管理部２４に送信する機能を有する点と、リソース管理部２４が統計情報に基づいて診断を実行すべきか否かを判定する点とが第１の実施の形態と異なる。統計情報は、システムリソースの負荷情報を示すものであって、たとえば、システムリソースに対する単位時間あたりのアクセス数等がある。
【０１１９】
第２の実施の形態の構成は、第１の実施の形態と同じく図１で示される。また、図２におけるシステムリソースを増設した場合の動作、図４における要求されたサービス対して未使用かつ正常なシステムリソースを割り当てる場合の動作は、第１の実施の形態と同様である。
【０１２０】
図１４は、第２の実施の形態のリソース管理データ記憶部３０およびリソース管理データ３００の構造を示す図である。第２の実施の形態のリソース管理データ３００は、第１の実施の形態のリソース管理データ２００と比べると、診断間隔２０６がなく、単位時間のアクセス数３０１と、閾値３０２とが追加されている。単位時間のアクセス数３０１は、システムリソースが単位時間当たりにアクセスされた回数であり、システムリソースの負荷の状況を示す負荷状況値である。閾値３０２は、単位時間のアクセス数３０１に対する上限値である。
【０１２１】
図１５は、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７が、統計情報を収集し、リソース管理部２４に送信する動作のフローチャートである。
【０１２２】
ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７は、統計情報として単位時間のアクセス数３０１を収集する（ステップＤ１０）。なお、単位時間は、ＷＥＢアプリケーション１８６およびＤＢアプリケーション１８７それぞれの特性に応じて、たとえば数分であってもよいし、数時間であってもよい。また、アクセス数は、ＷＥＢアプリケーション１８６の場合、読み出されたファイル数を用いてもよく、ＤＢアプリケーション１８７の場合、検索の問い合わせ数を用いてもよい。
【０１２３】
そして、ＷＥＢアプリケーション１８６またはＤＢアプリケーション１８７は、リソース管理部２４に、単位時間のアクセス数３０１を送信する（ステップＤ１２）。
【０１２４】
次に、リソース管理部２４は、受け取った単位時間のアクセス数３０１に基づいてリソース管理データ３００を更新する（ステップＤ１４）。
【０１２５】
図１６は、リソース管理部２４が統計情報に基づいて診断を実行すべきシステムリソースを抽出する動作のフローチャートである。
【０１２６】
リソース管理部２４は、あらかじめ定められた抽出間隔で、リソース管理データ３００を参照し、単位時間のアクセス数３０１が閾値３０２を越えているシステムリソースが存在するか否かを確認する（閾値３０２を超えているか？）（ステップＥ１２）。なお、あらかじめ定められた抽出間隔は、実施の形態１で説明したものと同じであってよい。たとえば、リソース管理部２４は、図１４に示す値を保持した状態のリソース管理データ３００を参照した場合、サーバ１６の単位時間のアクセス数３０１『２０００』が、閾値３０２『１８００』を越えていることを検出する。
【０１２７】
そして、単位時間のアクセス数３０１が閾値３０２を越えているシステムリソースが存在しなかった場合（ステップＥ１２でＮＯ）、リソース管理部２４は、本処理を終了する（ステップＥ９９）。
【０１２８】
そして、単位時間のアクセス数３０１が閾値３０２を越えているシステムリソースが存在した場合（ステップＥ１２でＹＥＳ）（リソース管理データ３００が図１４に示す値を保持しているならば、サーバ１６が存在する）、リソース管理部２４は、状態２０４が『未使用』のリソース管理データ３００が存在するか否かを確認する（未使用有り？）（ステップＥ１４）。
【０１２９】
そして、状態２０４が『未使用』のリソース管理データ３００が存在しない場合、（ステップＥ１４でＮＯ）、リソース管理部２４は、本処理を終了する（ステップＥ９９）。
【０１３０】
そして、状態２０４が『未使用』のリソース管理データ３００が存在する場合（ステップＥ１４でＹＥＳ）（リソース管理データ３００が図１４に示す値を保持しているならば、サーバ１９およびサーバ１８が存在する）、リソース管理部２４は、対応するシステムリソース（ここでは、サーバ１９およびサーバ１８）を診断すべきシステムリソースとして抽出する（ステップＥ１６）。
【０１３１】
以後の動作は、第１の実施形態で説明した図３のステップＢ１４以降の動作と同じであるため省略する。
【０１３２】
次に、ユーザ端末３からリソース管理データ３００を変更する動作について説明する。
【０１３３】
ユーザ端末３は、管理サーバ２に対してシステムリソース名２０２および閾値３０２を含むリソース管理データ変更指示（図示しない）を送信する。管理サーバ２のリソース管理部２４は、受信したリソース管理データ変更指示で指定されたシステムリソース名２０２に対応するリソース管理データ３００の閾値３０２を変更する。
【０１３４】
本実施の形態は、図１３に示すブロック図の構成においても、その特徴を有している。
【０１３５】
すなわち、リソース管理部２４は、使用中のシステムリソースの負荷状況値すなわち単位時間のアクセス数３０１が閾値３０２を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定する。
【０１３６】
そして、診断処理部２３は、リソース管理部２４において診断対象であると判定されたシステムリソースを起動し、診断を実行させる。
【０１３７】
本実施の形態の効果は、診断回数を適正にできることである。その理由は、診断を実行すべきシステムリソースの抽出ステップを実行するか否かを、使用中のシステムリソースの単位時間のアクセス数と閾値とに基づいて判定するようにしたからである。
【０１３８】
以上の実施の形態で説明した各構成要素は、たとえば、プログラムにより所定の処理をコンピュータに実行させてもよい。
【０１３９】
また、以上の実施の形態で説明した各構成要素は、必ずしも個々に独立した存在である必要はなく、複数の構成要素が一個のモジュールとして実現されていること、ひとつの構成要素が複数のモジュールで実現されていること、ある構成要素が他の構成要素の一部であること、ある構成要素の一部と他の構成要素の一部とが重複していること、等でもよい。
【０１４０】
また、以上説明した、実施の形態では、複数の動作をフローチャートの形式で順番に記載してあるが、その記載の順番は複数の動作を実行する順番を限定するものではない。このため、本実施の形態を実施するときには、その複数の動作の順番は内容的に支障しない範囲で変更することができる。
【０１４１】
さらに、以上説明した、実施の形態では、複数の動作は個々に相違するタイミングで実行されることに限定されない。このため、ある動作の実行中に他の動作が発生すること、ある動作の実行タイミングと他の動作の実行タイミングとの一部ないし全部が重複していること、等でもよい。
【０１４２】
さらに、以上説明した、実施の形態では、ある動作が他の動作の契機になるように記載しているが、その記載はある動作と他の動作のすべての関係を限定するものではない。このため、本実施の形態を実施するときには、その複数の動作の関係は内容的に支障しない範囲で変更することができる。また各構成要素の各動作の具体的な記載は、各構成要素の各動作を限定するものではない。このため、各構成要素の具体的な各動作は、本実施の形態を実施する上で機能的、性能的、その他の特性に対して支障をきたさない範囲内で変更されて良い。
【０１４３】
なお、以上説明した、実施の形態は、ハードウェアで実現されても良いし、ソフトウェアで実現されても良いし、ハードウェアとソフトウェアの混在により実現されても良い。
【０１４４】
また、各構成要素の物理的な構成は、以上の実施の形態の記載に限定されることはなく、独立して存在しても良いし、組み合わされて存在しても良いしまたは分離して構成されても良い。
【産業上の利用可能性】
【０１４５】
本発明は、プロビジョニングシステム等のシステムリソース管理に適用できる。
【図面の簡単な説明】
【０１４６】
【図１】本発明の第１および第２の実施の形態の構成を示すブロック図である。
【図２】本発明の第１および第２の実施の形態におけるシステムリソースを増設する動作を示すフローチャートである。
【図３】本発明の第１および第２の実施の形態における未使用のシステムリソースの診断を実行する動作を示すフローチャート
【図４】本発明の第１および第２の実施の形態における要求されるサービスに正常な未使用のシステムリソースを割り当てる動作を示すフローチャートである。
【図５】本発明の第１の実施の形態におけるリソース管理データ記憶部と、リソース管理データとの構造を示す図である。
【図６】本発明の第１および第２の実施の形態におけるサービス管理データ記憶部と、サービス管理データとの構造を示す図である。
【図７】本発明の第１および第２の実施の形態における診断実行指示の構造を示す図である。
【図８】本発明の第１および第２の実施の形態における診断プログラムの実行結果の構造を示す図である。
【図９】本発明の第１および第２の実施の形態における診断結果の構造を示す図である。
【図１０】本発明の第１および第２の実施の形態におけるＰＸＥブートの動作を示すシーケンス図である。
【図１１】本発明の第１および第２の実施の形態におけるサービス要求の構造を示す図である。
【図１２】本発明の第１および第２の実施の形態におけるサービス開始指示の構造を示す図である。
【図１３】本発明の第１および第２の実施の形態における特徴的な構成を示すブロック図である。
【図１４】本発明の第２の実施の形態におけるサービス管理データ記憶部と、サービス管理データとの構造を示す図である。
【図１５】本発明の第２の実施の形態におけるアプリケーションが統計情報を収集しリソース管理部に送信する動作のフローチャートである。
【図１６】本発明の第２の実施の形態におけるリソース管理部が統計情報に基づいて診断を実行すべきシステムリソースを抽出する動作のフローチャートである。
【符号の説明】
【０１４７】
１ 業務サーバ群
１６ サーバ
１６〜１９ サーバ
１７ サーバ
１８ サーバ
１８５ 診断プログラム
１８６ ＷＥＢアプリケーション
１８７ ＤＢアプリケーション
１９ サーバ
２ 管理サーバ
２０ リソース管理データ記憶部
２００ リソース管理データ
２０１ リソース識別子
２０２ システムリソース名
２０３ サービス名
２０４ 状態
２０５ 診断日時
２０６ 診断間隔
２０７ 最新診断結果
２０８ 診断フラグ
２０９ 要求フラグ
２１ サービス管理データ記憶部
２１０ サービス管理データ
２１２ ＮＢＰ名
２２ サービス処理部
２３ 診断処理部
２４ リソース管理部
２５ ＮＢＰ記憶部
２５５ 診断ＮＢＰ
２５６ ＷＥＢＮＢＰ
２５７ ＤＢＮＢＰ
３ ユーザ端末
３０ リソース管理データ記憶部
３００ リソース管理データ
３０１ 単位時間のアクセス数
３０２ 閾値
４ 監視端末
４００ サービス要求
５ ネットワーク
５００ サービス開始指示
６ ＤＨＣＰサーバ
６００ 診断実行指示
７０１ 実行結果
７０３ 診断結果
８ ファイルサーバ
【特許請求の範囲】
【請求項１】
システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定するリソース管理部と、
前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部と
を有することを特徴とする情報処理装置。
【請求項２】
使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定するリソース管理部と、
前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部と
を有することを特徴とする情報処理装置。
【請求項３】
前記システムリソースの前記診断間隔時間を変更する手段
を有することを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記閾値を変更する手段
を有することを特徴とする請求項２記載の情報処理装置。
【請求項５】
前記診断処理部は、前記システムリソースが起動時に送信したプログラム要求を受信した場合に、診断プログラムまたは前記診断プログラムを取得するための情報を送信する診断処理部
を有することを特徴とする請求項１ないし４のいずれかに記載の情報処理装置。
【請求項６】
未使用であり最新の診断結果が正常である前記システムリソースを、追加対象のシステムリソースとして選択する前記リソース管理部
を有することを特徴とする請求項１ないし５のいずれかに記載の情報処理装置。
【請求項７】
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、アプリケーションプログラムまたは前記アプリケーションプログラムを取得するための情報を送信するサービス処理部
を有することを特徴とする請求項６記載の情報処理装置。
【請求項８】
前記システムリソースのリソース識別子、システムリソース名、状態、診断日時、診断間隔および最新診断結果を少なくとも含むリソース管理データを記憶するリソース管理データ記憶部
を有することを特徴とする請求項１、３、５ないし７のいずれかに記載の情報処理装置。
【請求項９】
前記システムリソースのリソース識別子、システムリソース名、状態、診断日時、負荷状況値、負荷情報値に対する閾値および最新診断結果を少なくとも含むリソース管理データを記憶するリソース管理データ記憶部を
有することを特徴とする請求項２、４、５ないし７のいずれかに記載の情報処理装置。
【請求項１０】
コンピュータが、
システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
ことを特徴とする判定方法。
【請求項１１】
コンピュータが、
使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
ことを特徴とする判定方法。
【請求項１２】
コンピュータが、
前記システムリソースの前記診断間隔時間を変更する
ことを特徴とする請求項１０記載の判定方法。
【請求項１３】
コンピュータが、
前記閾値を変更する
ことを特徴とする請求項１１記載の判定方法。
【請求項１４】
コンピュータが、
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、診断プログラムまたは前記診断プログラムを取得するための情報を送信する
ことを特徴とする請求項１０ないし１３のいずれかに記載の判定方法。
【請求項１５】
コンピュータが、
未使用であり最新の診断結果が正常である前記システムリソースを、追加対象のシステムリソースとして選択する
ことを特徴とする請求項１０ないし１４のいずれかに記載の判定方法。
【請求項１６】
コンピュータが、
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、アプリケーションプログラムまたは前記アプリケーションプログラムを取得するための情報を送信する
ことを特徴とする請求項１５記載の判定方法。
【請求項１７】
システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
処理をコンピュータに実行させることを特徴とする判定プログラム。
【請求項１８】
使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
処理をコンピュータに実行させることを特徴とする判定プログラム。
【請求項１９】
前記システムリソースの前記診断間隔時間を変更する
処理をコンピュータに実行させることを特徴とする請求項１７記載の判定プログラム。
【請求項２０】
前記閾値を変更する
処理をコンピュータに実行させることを特徴とする請求項１８記載の判定プログラム。
【請求項２１】
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、診断プログラムまたは前記診断プログラムを取得するための情報を送信する
処理をコンピュータに実行させることを特徴とする請求項１７ないし２０のいずれかに記載の判定プログラム。
【請求項２２】
未使用であり最新の診断結果が正常である前記システムリソースを、追加対象のシステムリソースとして選択する
処理をコンピュータに実行させることを特徴とする請求項１７ないし２１のいずれかに記載の判定プログラム。
【請求項２３】
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、アプリケーションプログラムまたは前記アプリケーションプログラムを取得するための情報を応答する
処理をコンピュータに実行させることを特徴とする請求項２２記載の判定プログラム。
【請求項２４】
ネットワークに接続された、
請求項１ないし９のいずれかの前記情報処理装置と、
前記システムリソースと、
を有することを特徴とするプロビジョニングシステム。
【請求項１】
システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定するリソース管理部と、
前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部と
を有することを特徴とする情報処理装置。
【請求項２】
使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定するリソース管理部と、
前記リソース管理部において診断対象であると判定された前記システムリソースに診断を実行させる診断処理部と
を有することを特徴とする情報処理装置。
【請求項３】
前記システムリソースの前記診断間隔時間を変更する手段
を有することを特徴とする請求項１記載の情報処理装置。
【請求項４】
前記閾値を変更する手段
を有することを特徴とする請求項２記載の情報処理装置。
【請求項５】
前記診断処理部は、前記システムリソースが起動時に送信したプログラム要求を受信した場合に、診断プログラムまたは前記診断プログラムを取得するための情報を送信する診断処理部
を有することを特徴とする請求項１ないし４のいずれかに記載の情報処理装置。
【請求項６】
未使用であり最新の診断結果が正常である前記システムリソースを、追加対象のシステムリソースとして選択する前記リソース管理部
を有することを特徴とする請求項１ないし５のいずれかに記載の情報処理装置。
【請求項７】
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、アプリケーションプログラムまたは前記アプリケーションプログラムを取得するための情報を送信するサービス処理部
を有することを特徴とする請求項６記載の情報処理装置。
【請求項８】
前記システムリソースのリソース識別子、システムリソース名、状態、診断日時、診断間隔および最新診断結果を少なくとも含むリソース管理データを記憶するリソース管理データ記憶部
を有することを特徴とする請求項１、３、５ないし７のいずれかに記載の情報処理装置。
【請求項９】
前記システムリソースのリソース識別子、システムリソース名、状態、診断日時、負荷状況値、負荷情報値に対する閾値および最新診断結果を少なくとも含むリソース管理データを記憶するリソース管理データ記憶部を
有することを特徴とする請求項２、４、５ないし７のいずれかに記載の情報処理装置。
【請求項１０】
コンピュータが、
システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
ことを特徴とする判定方法。
【請求項１１】
コンピュータが、
使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
ことを特徴とする判定方法。
【請求項１２】
コンピュータが、
前記システムリソースの前記診断間隔時間を変更する
ことを特徴とする請求項１０記載の判定方法。
【請求項１３】
コンピュータが、
前記閾値を変更する
ことを特徴とする請求項１１記載の判定方法。
【請求項１４】
コンピュータが、
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、診断プログラムまたは前記診断プログラムを取得するための情報を送信する
ことを特徴とする請求項１０ないし１３のいずれかに記載の判定方法。
【請求項１５】
コンピュータが、
未使用であり最新の診断結果が正常である前記システムリソースを、追加対象のシステムリソースとして選択する
ことを特徴とする請求項１０ないし１４のいずれかに記載の判定方法。
【請求項１６】
コンピュータが、
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、アプリケーションプログラムまたは前記アプリケーションプログラムを取得するための情報を送信する
ことを特徴とする請求項１５記載の判定方法。
【請求項１７】
システムリソースの最近の診断日時からの経過時間が当該システムリソースに対応する診断間隔時間を越えた場合、当該システムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
処理をコンピュータに実行させることを特徴とする判定プログラム。
【請求項１８】
使用中のシステムリソースの負荷状況値が閾値を超えた場合に、未使用のシステムリソースを診断対象のシステムリソースであると判定し、
診断対象であると判定された前記システムリソースに診断を実行させる
処理をコンピュータに実行させることを特徴とする判定プログラム。
【請求項１９】
前記システムリソースの前記診断間隔時間を変更する
処理をコンピュータに実行させることを特徴とする請求項１７記載の判定プログラム。
【請求項２０】
前記閾値を変更する
処理をコンピュータに実行させることを特徴とする請求項１８記載の判定プログラム。
【請求項２１】
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、診断プログラムまたは前記診断プログラムを取得するための情報を送信する
処理をコンピュータに実行させることを特徴とする請求項１７ないし２０のいずれかに記載の判定プログラム。
【請求項２２】
未使用であり最新の診断結果が正常である前記システムリソースを、追加対象のシステムリソースとして選択する
処理をコンピュータに実行させることを特徴とする請求項１７ないし２１のいずれかに記載の判定プログラム。
【請求項２３】
前記システムリソースが起動時に送信したプログラム要求を受信した場合に、アプリケーションプログラムまたは前記アプリケーションプログラムを取得するための情報を応答する
処理をコンピュータに実行させることを特徴とする請求項２２記載の判定プログラム。
【請求項２４】
ネットワークに接続された、
請求項１ないし９のいずれかの前記情報処理装置と、
前記システムリソースと、
を有することを特徴とするプロビジョニングシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【公開番号】特開２０１０−１５２１４（Ｐ２０１０−１５２１４Ａ）
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願番号】特願２００８−１７１９８６（Ｐ２００８−１７１９８６）
【出願日】平成２０年７月１日（２００８．７．１）
【出願人】（０００２３２１４０）ＮＥＣフィールディング株式会社 (373)
【Ｆターム（参考）】
【公開日】平成２２年１月２１日（２０１０．１．２１）
【国際特許分類】
【出願日】平成２０年７月１日（２００８．７．１）
【出願人】（０００２３２１４０）ＮＥＣフィールディング株式会社 (373)
【Ｆターム（参考）】
[ Back to top ]