JP4932877B2 - 業務リソース管理方法及びその実施システム - Google Patents

Description

本発明はプログラムをその稼働条件に適したリソースへ配置するプログラム配置技術に関するものである。

従来、各種業務の処理を行う業務アプリケーションプログラム（業務プログラムともいう、以下ＡＰと略す）は複数のサーバ処理装置で実行して、その業務サービスをクライアント処理装置へ提供する場合、種々のＣＰＵ性能やメモリ容量を持つ各種サーバ処理装置やストレージ容量の異なる各種ストレージ装置等のリソースに、業務ＡＰやその処理で用いられるデータを配置して業務ＡＰを実行している。

また前記業務ＡＰを実行しているサーバ処理装置やストレージ装置の稼働状況に応じ、例えばあるサーバのＣＰＵ使用率が高くなった場合やストレージ装置の残容量が少なくなった場合等の所定の運用定義に従って、業務ＡＰを実行するサーバ処理装置やデータを格納するストレージ装置を変更することも行われている。

前記従来技術では、各種業務ＡＰを実行するサーバの性能・容量の監視、ストレージ装置の性能・容量の監視、或いは複数のサーバから成るクラスタの監視等を行い、その監視結果に応じて業務ＡＰを配置し直して業務サービスを提供する様にしているが、各々の監視機能は独立に稼働しており、また実行中の業務とは無関係に監視が行われていた為、それらの監視結果に応じて各業務ＡＰに適した配置を行うことができないという問題があった。

例えば、あるサーバのＣＰＵ使用率やストレージの残容量が所定の値になった場合、ある業務ＡＰにとってその値は通常の状態であっても、他の業務ＡＰにとっては異常な状態という可能性があるが、従来技術では業務ＡＰとは無関係に監視を行っている為、負荷が上昇した場合に、その業務ＡＰに必要の無い再配置が行われたり、その業務ＡＰに必要な再配置が行われなかったりすることがあった。

本発明の目的は上記問題を解決し、各業務アプリケーションの稼働条件に合わせてリソースの管理を行うことが可能な技術を提供することにある。

本発明は、プログラムをその稼働条件に適したリソースへ配置するプログラム配置システムにおいて、業務アプリケーションの構成管理情報とリソースの構成管理情報とを関連付けた業務アプリケーション情報を生成して、業務アプリケーション単位で使用リソースを管理するものである。

本発明のプログラム配置システムでは、各業務ＡＰの稼働状況、稼働条件及び稼働履歴を格納する為の構成管理情報を生成しておき、各業務ＡＰの実行時にそれらの管理情報を収集して前記業務ＡＰの構成管理情報の内容を維持管理する処理を行う。

また、各リソースの性能や容量に関する状態を格納する為の構成管理情報を生成しておき、各リソースの稼働時にそれらの管理情報を収集して前記リソースの構成管理情報の内容を維持管理する処理を行う。

前記業務ＡＰの構成管理情報から、各業務ＡＰの使用するリソースの識別情報を読み出し、その識別情報で識別されるリソースの構成管理情報を各リソースの構成管理情報の中から読み出すことにより、当該業務ＡＰの構成管理情報と前記検索されたリソースの構成管理情報とを関連付けた業務ＡＰ情報を生成する。

次に各業務ＡＰの状態を判定する為の業務ＡＰ毎のポリシー管理ルールを参照し、前記業務ＡＰ情報中のリソースの構成管理情報が、対応する業務ＡＰにおけるリソース異常を検出する為のルールに該当するかどうかを判定し、その業務ＡＰにとってのリソース異常が生じていると判定された場合には、当該業務ＡＰでリソース異常が発生していることを示す情報を出力する。

また本発明では、業務ＡＰを起動する場合や、業務ＡＰの稼働中に前記の様にしてある業務ＡＰでリソース異常が検出された場合には、その業務ＡＰの稼働条件に適したリソースを各リソースの構成管理情報から検索し、検索されたリソースにその業務ＡＰを配置または移動して業務処理を実行させる実行制御によりクラスタリングを行う。その際、その業務処理で用いられるデータへのアクセスパスも同時に制御し、配置または移動されたリソースでそのデータへのアクセスが行える様にする。

本発明では、クラスタリングとデータへのアクセスパスを、それぞれ「クラスタ管理プログラム」と「データパス管理プログラム」という用語を使用して表現している。「クラスタ管理プログラム」とは、業務ＡＰを安定稼働させる為、複数台のコンピュータ上で稼働するプログラムであり、業務ＡＰの状態監視や起動・終了を管理するプログラムである。また「データパス管理プログラム」とは、サーバ上で稼働する業務ＡＰが、業務データを参照・追加・変更・削除する為に、コンピュータとストレージ又はコンピュータとネットワークとストレージ間の通信路を管理するプログラムである。データパス管理プログラムは、通信路の確立や終了の管理と、通信路の状態の監視、及び通信路のルーティングを管理する。本発明では、業務ＡＰを稼働させる為に、「クラスタ管理プログラム」と「データパス管理プログラム」を使用して、業務ＡＰと業務ＡＰが使用する業務データを制御する。「クラスタ管理プログラム」と「データパス管理プログラム」の動作説明の一例を図５３に示す。

更に本発明では、各リソースが実際に設置されている領域をプライベートドメイン、仮想的にリソースが設置される領域をパブリックドメインとし、複数のプライベートドメインに設置された各リソースの構成管理情報を参照して所定時間稼働していない等の余剰リソースが存在しているかどうかを調べ、余剰リソースが存在している場合には、その構成管理情報をプライベートドメインからパブリックドメインへ提供することにより、リソースが仮想的にパブリックドメインへ移動したものとして管理し、前記業務ＡＰの起動時やリソース異常検出時にその業務ＡＰの稼働条件に合うリソースが見つからない場合には、前記パブリックドメインからその稼働条件に合う余剰リソースの構成管理情報を当該プライベートドメインへ貸し出すことにより、あるプライベートドメイン内に設置されている余剰リソースを他のプライベートドメインから利用可能とする。

本発明で使用する「プライベートドメイン」と「パブリックドメイン」の用語を説明する。「プライベートドメイン」とは、複数のサーバやストレージがネットワークで接続されており、リソースを管理する管理者が同じであるとか、同じ場所にリソースを配信しているとかの要因により分類される論理的な単位のことを言う。例えば、複数社のリソースが設置されているコンピュータセンターにおいては、Ａ社用のリソースを一つのプライベートドメインとして管理でき、Ｂ社用のリソースは別のプライベートドメインとして管理できる。また一つの会社においては、Ｃ事業所のリソースを一つのプライベートドメインとして管理でき、Ｄ事業所のリソースは別のプライベートドメインとして管理できる。これに対して「パブリックドメイン」とは、仮想的なコンピュータシステムのことであり、プライベートドメインとの間で余剰リソースの受け渡しを仮想的に行う。例えば、Ｅ社の本社にリソースが豊富に存在する場合、本社はパブリックドメイン及びプライベートドメインの両方を設置でき、余剰リソースをＣ事業所やＤ事業所に貸し出すことができる。

また本発明では、前記業務ＡＰでのリソース異常を検出する為のルールや、前記余剰リソースを検出する為のルールを含むポリシー管理ルールを一元管理し、それらのルールが変更された場合にはその変更されたルールを各プライベートドメインへ配布してポリシーを統合管理する。

前記の様に本発明では、業務ＡＰ情報で業務ＡＰの使用リソースを関連付けることにより、業務ＡＰ単位に使用するリソース毎の管理を行うので、業務ＡＰ毎のリソース異常の検知等の当該業務に適したリソースの管理、各業務の稼働条件に適した実行制御や余剰リソースの提供、及びそれらを行う為のポリシー管理ルールの統合管理を行うことができる。

以上の様に本発明のプログラム配置システムによれば、業務アプリケーションの構成管理情報とリソースの構成管理情報とを関連付けた業務アプリケーション情報を生成して、業務アプリケーション単位で使用リソースを管理するので、各業務アプリケーションの稼働条件に合わせてリソースの管理を行うことが可能である。

本発明によれば業務アプリケーションの稼働条件に合わせてリソースの管理を行うことが可能である。

本実施形態のプログラム配置システムの概要を示す図である。 本実施形態のプログラム配置システムの機能階層を示す図である。 本実施形態の管理及び制御される監視対象物のレイヤ構造を示す図である。 本実施形態の構成管理情報の構成例を示す図である。 本実施形態の業務ＡＰの管理情報の構成例を示す図である。 本実施形態のＡＰ稼働情報の構成例を示す図である。 本実施形態のＡＰ稼働条件の構成例を示す図である。 本実施形態のＡＰ稼働履歴の構成例を示す図である。 本実施形態のサーバ管理情報の構成例を示す図である。 本実施形態のサーバハード情報の構成例を示す図である。 本実施形態のＯＳ情報の構成例を示す図である。 本実施形態のＤＢ情報の構成例を示す図である。 本実施形態のクラスタ／データパス情報の構成例を示す図である。 本実施形態のストレージ管理情報の構成例を示す図である。 本実施形態の管理情報の関連付けの概要を示す図である。 本実施形態の管理情報の関連付け処理の処理内容を示す図である。 本実施形態のＯＳ情報サーチ処理の処理内容を示す図である。 本実施形態の論理ホスト名サーチ処理の処理内容を示す図である。 本実施形態のＤＢ情報サーチ処理の処理内容を示す図である。 本実施形態のクラスタ／データパス情報サーチ処理の処理内容を示す図である。 本実施形態のストレージ管理情報サーチ処理の処理内容を示す図である。 本実施形態の関連付けた業務ＡＰ情報の例を示す図である。 本実施形態の図２２の業務ＡＰの問題点と対策の例を示す図である。 本実施形態のポリシー管理ルールの例を示す図である。 本実施形態のポリシー管理ルールの配布処理の処理内容を示す図である。 本実施形態の業務ＡＰ起動時の実行管理処理の処理内容を示す図である。 本実施形態のリソースのスケジュール予約のイメージを示す図である。 本実施形態のプライベートドメイン２の空間スケジューラ４４の処理内容を示す図である。 本実施形態の業務ＡＰ実行サーバの確認処理の処理内容を示す図である。 本実施形態の業務実行サーバの変更処理の処理内容を示す図である。 本実施形態の論理ホストの確認処理の処理内容を示す図である。 本実施形態のリソーススケジュール予約処理の処理内容を示す図である。 本実施形態の業務ＡＰの特定と対処を行う処理内容を示す図である。 本実施形態の業務ＡＰのクラスタリング処理の処理内容を示す図である。 本実施形態のクラスタリングサーバ名の確認処理の処理内容を示す図である。 本実施形態の余剰サーバの判定処理の処理内容を示す図である。 本実施形態のリソース予約の確認処理の処理内容を示す図である。 本実施形態のプライベートドメイン２の構成管理処理部４１の処理内容を示す図である。 本実施形態の管理情報要求受信処理の処理内容を示す図である。 本実施形態のパブリックドメイン１の構成管理処理部３１の処理内容を示す図である。 本実施形態のパブリックドメイン１の空間スケジューラ３４の処理内容を示す図である。 本実施形態のプライベートドメイン２の性能・容量管理処理部４７の処理内容を示す図である。 本実施形態のプライベートドメイン２のクラスタ／データパス管理処理部４６の処理内容を示す図である。 本実施形態のＤＢ変更処理の処理内容を示す図である。 本実施形態のデータパス変更処理の処理内容を示す図である。 本実施形態の予測結果を反映するポリシー管理処理の処理内容を示す図である。 本実施形態のマシン及び業務ＡＰ単位のリソース使用状況把握例を示す図である。 本実施形態のマシン及び業務ＡＰ単位のリソース許容範囲例を示す図である。 本実施形態のマシン及び業務ＡＰ単位のリソース使用上限値の補正例を示す図である。 本実施形態のリソース使用上限値補正処理の処理内容を示す図である。 本実施形態のリソース使用傾向予測処理の処理内容を示す図である。 本実施形態の予測値反映処理の処理内容を示す図である。 本実施形態のクラスタ管理プログラムとデータパス管理プログラムの動作説明の図である。

以下に業務ＡＰをその稼働条件に適したリソースへ配置する一実施形態のプログラム配置システムについて説明する。

図１は本実施形態のプログラム配置システムの概要を示す図である。図１に示す様に本実施形態のプログラム配置システムは、複数のプライベートドメイン２とパブリックドメイン１から構成されており、これらのドメインは、ネットワーク３により接続されている。

本実施形態では、顧客が業務を運用しているドメインをプライベートドメイン２とする。プライベートドメイン２は、実際の業務を実行する複数のサーバを表すリアル業務サーバ群１０と、ストレージ筐体を複数持つことが可能で、実際の業務で用いられるデータを格納するリアルストレージ１３と、プライベートドメイン内の管理を行うプライベートドメイン管理サーバ１１と、各業務ＡＰ及びリソースの構成管理情報を格納するプライベートドメイン構成情報１２とを備えている。

プライベートドメイン管理サーバ１１は、リアル業務サーバ群１０とリアルストレージ１３を管理して、それらの構成情報及び状態情報をプライベートドメイン構成情報１２として管理する。

パブリックドメイン１は、パブリックドメイン管理サーバ２１により管理され、仮想業務サーバ群２０、仮想ストレージ２３、パブリックドメイン構成情報２２から構成する。パブリックドメイン構成情報２２は、プライベートドメイン構成情報１２から、プライベートドメイン２で余剰となったリアル業務サーバ群１０やリアルストレージ１３を一時的または恒久的に借り受けた場合に管理される構成管理情報である。パブリックドメイン構成情報２２は、借り受けたリアル業務サーバ群１０やリアルストレージ１３を返却する場合に、プライベートドメイン構成情報１２に対して行うものとする。つまり、仮想業務サーバ群２０の実体はリアル業務サーバ群１０に対応し、仮想ストレージ２３の実体はリアルストレージ１３に対応しているものとする。

任意のプライベートドメイン２でリソースが不足した場合は、パブリックドメイン１からリソースを借り受けるものとし、また、任意のプライベートドメイン２はパブリックドメイン１を代行することもできるものとする。

図２は本実施形態のプログラム配置システムの機能階層を示す図である。図２に示す様に本実施形態のパブリックドメイン管理サーバ２１は、運用監視処理部３０と、構成管理処理部３１と、ポリシー管理処理部３２と、空間スケジューラ３４とを有している。

運用監視処理部３０は、パブリックドメイン１内の他の機能コンポーネントである構成管理処理部３１〜空間スケジューラ３４の状態を監視する処理部である。構成管理処理部３１は、余剰リソースを検出する為のルールに該当するリソースの構成管理情報をプライベートドメイン２側の構成管理処理部４１から受信し、パブリックドメイン１中の仮想リソース３８の構成管理情報として維持管理する処理部である。

ポリシー管理処理部３２は、パブリックドメイン１内のポリシー管理ルールを管理する処理部である。空間スケジューラ３４は、業務ＡＰ４８の稼働条件を満たす構成管理情報を持つリソースが見つからない場合に送信されたリソースの提供要求をプライベートドメイン２側の空間スケジューラ４４から受信し、前記維持管理している仮想リソースの構成管理情報の内で業務ＡＰ４８の稼働条件を満たす構成管理情報を送信する処理部である。

パブリックドメイン管理サーバ２１を運用監視処理部３０、構成管理処理部３１、ポリシー管理処理部３２及び空間スケジューラ３４として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。

プライベートドメイン管理サーバ１１は、運用監視処理部４０と、構成管理処理部４１と、ポリシー管理処理部４２と、配布管理処理部４３と、空間スケジューラ４４と、実行管理処理部４５と、クラスタ／データパス管理処理部４６と、性能・容量管理処理部４７とを有している。

運用監視処理部４０は、プライベートドメイン２内の他の機能コンポーネントである構成管理処理部４１〜性能・容量管理処理部４７の状態を監視する処理部である。構成管理処理部４１は、各処理部で収集された管理情報を参照することにより各リソースの構成管理情報を維持管理し、各業務ＡＰ４８の使用するリソースの識別情報を含む構成管理情報を参照して、その識別情報で識別されるリソースの構成管理情報を各リソースの構成管理情報の中から読み出すことにより、業務ＡＰ４８の構成管理情報と前記検索されたリソースの構成管理情報とを関連付けた業務ＡＰ情報を生成し、前記業務ＡＰ情報中のリソースの構成管理情報が、対応する業務ＡＰ４８でのリソース異常を検出する為のルールに該当する場合に、業務ＡＰ４８でリソース異常が発生していることを示す情報を出力する処理部である。

ポリシー管理処理部４２は、業務ＡＰ４８でのリソース異常を検出する為のルール及び余剰リソースを検出する為のルールを含むポリシー管理ルールを一元管理する処理部である。配布管理処理部４３は、業務ＡＰ４８やＤＢ管理システム等のプログラムを、プライベートドメイン管理サーバ１１から任意のリアル業務サーバ４９へ配布する処理部である。

空間スケジューラ４４は、前記予約指示の行われた業務ＡＰ４８に関連付けられたリソースの構成管理情報が業務ＡＰ４８の構成管理情報中の稼働条件を満たす場合に、その業務ＡＰ４８を実行するリソースとして前記リソースを予約する処理部である。

実行管理処理部４５は、業務ＡＰ４８の実行要求を受信して業務ＡＰ４８で使用されるリソースの予約を指示し、前記指示によって予約の行われたリソースで業務ＡＰ４８を起動する処理や、業務ＡＰ４８を実行中のリソースに異常が検出された場合に、前記リソース異常の発生した業務ＡＰ４８の構成管理情報中の稼働条件を満たす構成管理情報を持つ他のリソースを検索し、その検索されたリソースで業務ＡＰ４８の処理を続行する処理を行う処理部である。

クラスタ／データパス管理処理部４６は、クラス管理プログラムの構成や状態の管理と、データパス管理プログラムが持つサーバ４９とストレージ５０間のデータパスの構成や状態及びデータパスの変更指示を管理する処理部である。性能・容量管理処理部４７は、各サーバ４９の性能やストレージ５０の容量等に関する状態を示す管理情報を収集して管理する処理部である。

プライベートドメイン管理サーバ１１を運用監視処理部４０、構成管理処理部４１、ポリシー管理処理部４２、配布管理処理部４３、空間スケジューラ４４、実行管理処理部４５、クラスタ／データパス管理処理部４６及び性能・容量管理処理部４７として機能させる為のプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。

図２の様にプライベートドメイン２のプライベートドメイン管理サーバ１１は、運用監視処理部４０、構成管理処理部４１（プライベートドメイン構成情報１２を管理する）、ポリシー管理処理部４２、配布管理処理部４３、空間スケジューラ４４、実行管理処理部４５、クラスタ／データパス管理処理部４６、性能・容量管理処理部４７を備え、複数存在できる業務ＡＰ４８やサーバ４９やストレージ５０を維持・管理している。

パブリックドメイン１のパブリックドメイン管理サーバ２１は、運用監視処理部３０、構成管理処理部３１（パブリックドメイン構成情報２２を管理する）、ポリシー管理処理部３２、空間スケジューラ３４を備え、プライベートドメイン２の余剰リソースを仮想リソース３８として維持・管理している。

性能・容量管理処理部４７は、業務ＡＰ４８とサーバ４９とストレージ５０の管理情報を収集して履歴を保存し、構成管理処理部４１から管理情報を要求されたときは収集している管理情報を応答する。

図３は本実施形態の管理及び制御される監視対象物のレイヤ構造を示す図である。図３の様に本実施形態において管理及び制御される監視対象物は、業務ＡＰ７０とサーバ８０とストレージ９０の各レイヤから構成されているものとし、業務ＡＰ７０には、Ｗｅｂアプリケーション７１とバッチジョブ７２とワークフロー７３があり、サーバ８０には、ＤＢ管理処理部８１とクラスタ／データパス管理処理部８２とＯＳ８３がある。

図４は本実施形態の構成管理情報の構成例を示す図である。図４に示す様に本実施形態の構成管理情報には、それぞれ業務ＡＰ、サーバ及びストレージの情報がある。

図５は本実施形態の業務ＡＰの管理情報の構成例を示す図である。図５の様に業務ＡＰの管理情報は、ＡＰ稼働状況、ＡＰ稼働条件及びＡＰ稼働履歴を示す情報を有している。

図６は本実施形態のＡＰ稼働情報の構成例を示す図である。図６の様にＡＰ稼働状況の情報は、業務ＡＰ名、業務ＡＰ実行ドメイン名、バッチ、Ｗｅｂ ＡＰ、ワークフロー等の業務ＡＰ種別、業務ＡＰ実行サーバ名、業務ＡＰ実行ユーザ名、業務ＡＰの時刻指定の有無を示す業務ＡＰ時刻指定有無、業務ＡＰ開始予定時刻、業務ＡＰ終了予定時刻、業務ＡＰ重要度、業務ＡＰ状態を格納している。

図７は本実施形態のＡＰ稼働条件の構成例を示す図である。図７の様にＡＰ稼働条件は、業務特性（定期実行ジョブ／オンライン／その他）、マシン使用形態（専用/共用）、データパス名、ＣＰＵ数、メモリ量、プロセス数、スレッド数、ディスク容量、論理ホスト名、クラスタリング可否フラグ、クラスタリンググループ名、使用ＤＢ名を格納している。また、プロセス数に対応したプロセス名と、スレッド数に対応したスレッド名を格納している。

図８は本実施形態のＡＰ稼働履歴の構成例を示す図である。図８の様にＡＰ稼働履歴は、ＡＰ稼働履歴時刻、ＣＰＵ使用率、メモリ使用量、プロセス使用数、スレッド使用数、業務ＡＰ名、ディスク使用容量、ＣＰＵ数、業務ＡＰ開始時刻、業務ＡＰ終了時刻、ＡＰ実行サーバ名、業務ＡＰ終了状態を格納している。

図９は本実施形態のサーバ管理情報の構成例を示す図である。図９の様にサーバ管理情報は、サーバハード情報としてＯＳ情報、ＤＢ情報、クラスタ/データパス情報を格納している。

図１０は本実施形態のサーバハード情報の構成例を示す図である。図１０の様にサーバハード情報は、単一、パーテーションやブレード等のサーバ種別、論理サーバ数、余剰ＣＰＵ数を格納しており、論理サーバ数に対応して、サーバ名、ＣＰＵ種別、ＣＰＵ数、他ドメインへのサーバ提供有無、ドメイン提供開始時刻、ドメイン提供終了時刻、ＯＳ情報を格納している。また、ＣＰＵ数に対応したＣＰＵ番号とＣＰＵ状態を格納している。

図１１は本実施形態のＯＳ情報の構成例を示す図である。図１１の様にＯＳ情報は、ＣＰＵ数、ＯＳ種別、最大メモリ量、使用メモリ量、残メモリ量、最大プロセス数、使用プロセス数、残プロセス数、最大スレッド数、使用スレッド数、残スレッド数、最大ディスク容量、使用ディスク容量、サーバ名、論理ホスト数（ｋ）、残ディスク容量、ＣＰＵ使用率、使用メモリ量率、使用プロセス数率、使用スレッド数率、ユーザ名数を有し、論理ホスト数に対応した論理ホスト名と、ユーザ名数に対応したユーザ名を格納している。

図１１の残プロセス数や残スレッド数等の残数の計算式は、ポリシー管理処理部によって設定されるものとし、デフォルトの計算式は最大数−使用数＝残数であり、ここで最大数及び使用数は、それぞれ前記の最大プロセス数や最大スレッド数等の数、使用プロセス数や使用スレッド数等の数である。

図１２は本実施形態のＤＢ情報の構成例を示す図である。図１２の様にＤＢ情報は、ＤＢ数毎に、ＤＢ名、ＤＢ状態、業務ＡＰ名、データ容量、データ容量履歴を有し、データ容量履歴としてデータ容量履歴時刻、データ容量履歴使用量を格納している。

またクラスタ／データパス管理処理部４６は、クラス管理プログラムの構成や状態の管理と、データパス管理プログラムが持つサーバ４９とストレージ５０間のデータパスの構成や状態及びデータパスの変更指示を管理する。クラスタ／データパスの管理情報を図１３に示す。

図１３は本実施形態のクラスタ／データパス情報の構成例を示す図である。図１３の様にクラスタ／データパス情報は、クラスタ運用有無、クラスタソフト名、クラスタ登録業務ＡＰ数、データパス有無、データパス数を有し、クラスタ登録業務ＡＰ数に対応した、業務ＡＰ名、業務ＡＰ状態、稼働サーバ名、稼働論理ホスト名、稼働データパス名と、データパス数に対応した、データパス名、データパス状態、ストレージ名、ストレージ論理ユニット名とを格納している。

図１４は本実施形態のストレージ管理情報の構成例を示す図である。図１４の様にストレージ管理情報は、ストレージ名、ストレージ容量、ストレージ論理ユニット数を有し、ストレージ論理ユニット数に対応したストレージ論理ユニット名、ストレージ論理ユニット容量、ストレージ論理ユニット使用容量、ストレージ論理ユニット残容量、ストレージの他ドメインへの提供有無、ストレージの他ドメインへの提供容量、ストレージの他ドメインへの提供開始時刻、ストレージの他ドメインへの提供終了時刻、ストレージ論理ユニットの使用履歴と、ストレージ履歴時刻、ストレージ履歴使用量とを格納している。

本実施形態の構成管理処理部４１は、性能・容量管理処理部４７とクラスタ／データパス管理処理部４６が収集した管理情報を参照することにより構成情報を維持管理し、またプライベートドメイン２の他の機能コンポーネントからの管理情報の参照や更新の要求を受付ける。特に空間スケジューラ４４が余剰と判断したリソースの構成管理情報を、パブリックドメイン１の構成管理処理部３１へ一時的又は恒久的に提供する。

配布管理処理部４３は、業務ＡＰ７０やＤＢ管理処理部８１等のプログラムを、プライベートドメイン管理サーバ１１から任意のリアル業務サーバへ配布する処理を行う。

空間スケジューラ４４は、構成管理処理部４１を通して、業務ＡＰのスケジュールやサーバ４９やストレージ５０の運用状態を監視して、余剰となったリソースが発生した場合は、その旨を構成管理処理部４１へ通知する処理を行う。

実行管理処理部４５は、業務ＡＰ７０の実行や終了を管理し、図８の業務ＡＰ開始時刻２５８や業務ＡＰ終了時刻２５９の管理情報は、実行管理処理部４５により構成管理処理部４１へ通知される。

ポリシー管理処理部４２は、構成管理処理部４１や性能・容量管理処理部４７やクラスタ／データパス管理処理部４６や空間スケジューラ４４の動作基準を設定及び変更する機能を持ち、構成管理処理部４１が余剰となったリソースをパブリックドメイン１の構成管理処理部３１へ提供する場合に該当するリソースが構成管理処理部３１からの参照権限を許可されているかを判断する為のアクセスコントロールリスト（ＡＣＬ）を持つ。

性能・容量管理処理部４７では、図１１の残メモリ量３５４や残プロセス数３５７や残スレッド数３６０や残ディスク容量３６５を算出する為の計算式を変更できるものとする。例えば、残メモリ量３５４のデフォルト計算式は、（残メモリ量３５４）＝（最大メモリ量３５２）―（使用メモリ量３５３）であるが、ポリシー管理により使用メモリ量３５３に安全係数αを設定すると、（残メモリ量３５４）＝（最大メモリ量３５２）―（使用メモリ量３５３）×（安全係数α）の様に、残メモリ量を変更することができる。また空間スケジューラ４４も同様に、安全係数を加味することにより余剰リソースの判断を変更できるものとする。

クラスタ／データパス管理処理部４６については、時間帯により図６の業務ＡＰ重要度２２８を変更することによりクラスタリングさせる業務ＡＰ７０の選択を変更したり、クラスタリング先のサーバを任意のリソースの残量により変更できるものとする。
また運用監視処理部４０は、プライベートドメイン２の他の機能コンポーネントの状態を監視する処理を行う。

一方、パブリックドメイン１は、運用監視処理部３０、構成管理処理部３１（パブリックドメイン構成情報２２を管理する）、ポリシー管理処理部３２、空間スケジューラ３４から構成され、構成管理を通して仮想リソース３８を維持、管理する。

構成管理処理部３１は、一つ又は複数のプライベートドメイン２の構成管理処理部４１から提供されたリソースを仮想リソース３８として維持管理する。あるプライベートドメイン２の構成管理処理部４１からの借用期限のきたリソースの通知や空間スケジューラ３４からの使用が終了した旨の通知を受け、そのリソースを提供元のプライベートドメイン２の構成管理処理部４１へ返却する。

空間スケジューラ３４は、構成管理処理部３１に存在する仮想リソース３８を、その借用期限を考慮して維持管理し、リソースの提供要求を受付けると、その要求条件に合致した仮想リソースを提供する。また、使用期限のきた仮想リソースを構成管理処理部３１へ通知する。

ポリシー管理処理部３２は、空間スケジューラ３４の動作基準を設定及び変更する機能を持ち、空間スケジューラ３４が、複数のプライベートドメイン２から仮想リソースの提供依頼を受けた場合、どのプライベートドメイン２を優先するかを変更できるものとする。
また運用監視処理部３０は、パブリックドメイン１の他の機能コンポーネントの状態を監視する処理を行う。

次に、本実施形態のプログラム配置システムにおいて、業務ＡＰの構成管理情報とリソースの構成管理情報とを関連付けることにより、業務ＡＰ単位に使用するリソース毎の管理を行い、業務ＡＰ毎のリソース異常の検知等の当該業務に適したリソースの管理を実行して業務ＡＰの安定稼働を実現する処理について説明する。

本実施形態のプライベートドメイン管理サーバ１１の構成管理処理部４１は、各処理部で収集された管理情報を参照することにより各リソースの構成管理情報を維持管理し、各業務ＡＰ４８の使用するリソースの識別情報を含む構成管理情報を参照して、その識別情報で識別されるリソースの構成管理情報を各リソースの構成管理情報の中から読み出すことにより、業務ＡＰ４８の構成管理情報と前記検索されたリソースの構成管理情報とを関連付けた業務ＡＰ情報を生成し、前記業務ＡＰ情報中のリソースの構成管理情報が、対応する業務ＡＰ４８でのリソース異常を検出する為のルールに該当する場合に、業務ＡＰ４８でリソース異常が発生していることを示す情報を出力する処理を行う。このリソース異常に対して、稼働条件を満たすサーバへのクラスタリング等の対策を施すことにより、業務ＡＰの安定稼働を実現することができる。

図１５は本実施形態の管理情報の関連付けの概要を示す図である。図１５の様に、（１）サーバ名の一致、（２）サーバ名の一致、（３）数に対応する論理ホスト名の一致、（４）ＤＢ名の一致、（５）業務ＡＰ名の一致、（６）データパス名の一致、（７）ストレージ名とストレージ論理ユニット名の一致の様に、一致する情報を検索していくことにより、各管理情報の関連付けを行う。

図１６は本実施形態の管理情報の関連付け処理の処理内容を示す図である。ステップ１６０１でプライベートドメイン管理サーバ１１の構成管理処理部４１は、業務ＡＰ数２０１で示される数のループ制御を行う。

ステップ１６０２では、業務ＡＰ実行サーバ名２２３とサーバ管理情報のサーバ名３３０と一致するかどうかを調べ、一致する場合にはステップ１６０３以降の処理を行う。

ステップ１６０３では、フラグ１、フラグ２、フラグ３の値を格納する為の領域をメモリ上に確保した後、フラグ１＝０、フラグ２＝０、フラグ３＝０の様に各フラグの値を設定する。

ステップ１６０４〜ステップ１６０８では、ＯＳ情報リサーチ、論理ホスト名サーチ、ＤＢ情報サーチ、クラスタ／データパス情報サーチ、ストレージ管理情報サーチの各処理を実行する。

そしてステップ１６０９では、フラグ１の値を調べ、その値が「０」で有る場合にはステップ１６１０へ進み、そうでない場合にはステップ１６１１へ進む。

ステップ１６１０では、関連した情報の抽出成功として抽出した情報により、業務ＡＰ４８の構成管理情報と抽出されたリソースの構成管理情報とを関連付けた業務ＡＰ情報を生成する。一方、ステップ１６１１では、関係付けが失敗したことをディスプレイ装置等の出力装置へ出力し、管理者へ知らせる。

図１７は本実施形態のＯＳ情報サーチ処理の処理内容を示す図である。ステップ１７０１では、それまでの処理で設定されているフラグ１の値を調べ、その値が「０」で有る場合にはステップ１７０２へ進む。

ステップ１７０２では、サーバハード情報３１１のサーバ名３３０とＯＳ情報３１２のサーバ名３６３が一致するものがあるかどうかを調べ、一致するものがある場合にはステップ１７０３へ進み、そうでない場合にはステップ１７０４へ進む。ステップ１７０３では、一致したＯＳ情報３１２を抽出し、またステップ１７０４では、フラグ１に「１」を設定する。

図１８は本実施形態の論理ホスト名サーチ処理の処理内容を示す図である。ステップ１８０１では、フラグ１が「０」であるかどうかを調べ、フラグ１が「０」である場合にはステップ１８０２へ進む。

ステップ１８０２では、ＡＰ稼動条件２１２の論理ホスト名２３９と一致する論理ホスト名がＯＳ情報３１２の論理ホスト名３７０〜３７２に存在するかどうかを調べ、一致するものがある場合にはステップ１８０３へ進み、そうでない場合にはステップ１８０４へ進む。

ステップ１８０３では、一致した論理ホスト名を抽出し、ステップ１８０４では、フラグ１に「１」を設定する。

図１９は本実施形態のＤＢ情報サーチ処理の処理内容を示す図である。ステップ１９０１では、フラグ１が「０」であるかどうかを調べ、フラグ１が「０」である場合にはステップ１９０２へ進む。

ステップ１９０２では、ＡＰ稼動条件２１１の業務ＡＰ名２２０かつＡＰ稼動条件２１２の使用ＤＢ名２４２の組み合せと一致するＤＢ名３９０と業務ＡＰ３９２は存在するかどうかを調べ、一致するものがある場合にはステップ１９０３へ進み、そうでない場合にはステップ１９０４へ進む。

ステップ１９０３では、一致したＤＢ情報３９０〜４０１を抽出し、ステップ１９０４では、フラグ１に「１」を設定する。

図２０は本実施形態のクラスタ／データパス情報サーチ処理の処理内容を示す図である。ステップ２００１では、フラグ１が「０」であるかどうかを調べ、フラグ１が「０」である場合にはステップ２００２へ進む。

ステップ２００２では、クラスタ運用有無５００は「無」となっているかどうかを調べ、「無」となっている場合にはステップ２００３へ進み、ステップ２００３では、クラスタ運用の無いことを示す戻り値を設定する。

ステップ２００４では、ＡＰ稼動状況２１１の業務ＡＰ名２２０と一致する業務ＡＰ名は存在するかどうかを調べ、一致するものがある場合にはステップ２００５へ進み、そうでない場合にはステップ２００６へ進む。

ステップ２００５では、一致したクラスタ情報５１０〜５１４を抽出し、またステップ２００６では、クラスタ運用対象外としてフラグ３に「１」を設定する。

ステップ２００７では、一致した稼動データパス名５１４と一致するデータパス名５２０は存在するかどうかを調べ、一致するものがある場合にはステップ２００８へ進み、そうでない場合にはステップ２００９へ進む。

ステップ２００８では、一致したデータパス情報（５２０〜５２３）を抽出し、またステップ２００９では、ストレージ運用対象外としてフラグ２に「１」を設定する。

図２１は本実施形態のストレージ管理情報サーチ処理の処理内容を示す図である。ステップ２１０１では、フラグ１が「０」であると共にフラグ２が「０」であるかどうかを調べ、フラグ１及び２の両方が「０」である場合にはステップ２１０２へ進む。

ステップ２１０２では、抽出したストレージ名５２２及びストレージ論理ユニット名５２３の組合せと一致する、ストレージ管理情報６１０のストレージ名６１１及びストレージ論理ユニット名６２０が存在するかどうかを調べ、存在する場合にはステップ２１０３へ進み、そうでない場合にはステップ２１０４へ進む。

ステップ２１０３では、一致したストレージ情報６２０〜６３１を抽出し、またステップ２１０４では、フラグ１に「１」を設定する。

図２２は本実施形態の関連付けた業務ＡＰ情報の例を示す図である。図２２に示す様に業務ＡＰ情報では、各業務ＡＰの構成管理情報とリソースの構成管理情報とを関連付けている。

各業務ＡＰの状態を判定する為の業務ＡＰ毎のポリシー管理ルールを参照し、前記業務ＡＰ情報中のリソースの構成管理情報が、対応する業務ＡＰにおけるリソース異常を検出する為のルールに該当するかどうかを判定することにより、その業務ＡＰにとってのリソース異常が生じているかどうかを判定することが可能であり、リソース異常が判定された場合には、例えば図２２の＊１〜３の表示を行い、各業務ＡＰでリソース異常が発生していることを示す情報を出力する。

図２３は本実施形態の図２２の業務ＡＰの問題点と対策の例を示す図である。図２３では、図２２で示した業務ＡＰの問題点とその対策例を示している。図２３の問題点に示された様なリソース異常を検出する際にはポリシー管理ルールが用いられる。

図２４は本実施形態のポリシー管理ルールの例を示す図である。図２４では、図２３の問題点や対策の生成時に用いられるポリシー管理ルールの例を表している。

次に、本実施形態のプログラム配置システムにおいて、前記の様なポリシー管理ルールを各機能コンポーネントへ配布して統合管理を行い、プログラム配置の自動運用を行える様にする処理について説明する。

本実施形態においてプライベートドメイン管理サーバ１１のポリシー管理処理部４２やパブリックドメイン管理サーバ２１のポリシー管理処理部３２は、業務ＡＰ４８でのリソース異常を検出する為のルール及び余剰リソースを検出する為のルールを含むポリシー管理ルールを一元管理する処理を行う。

図２５は本実施形態のポリシー管理ルールの配布処理の処理内容を示す図である。ステップ２５０１でプライベートドメイン管理サーバ１１のポリシー管理処理部４２は、追加、削除または変更の行われたポリシー管理ルールがあるかどうかを調べ、ある場合にはステップ２５０２へ進む。

ステップ２５０２では、配布先のドメインが自ドメインであるかどうかを調べ、自ドメインである場合にはステップ２５０３へ進み、そうでない場合にはステップ２５０９へ進む。

ステップ２５０３では、ポリシー管理ルールへの処理内容がポリシー管理ルールの追加の場合であるかどうかを調べ、追加である場合にはステップ２５０４へ進む。ステップ２５０４では、追加されたポリシー管理ルールを配布先へ配布する。
ステップ２５０５では、ポリシー管理ルールへの処理内容がポリシー管理ルールの削除の場合であるかどうかを調べ、削除である場合にはステップ２５０６へ進む。ステップ２５０６では、削除されたポリシー管理ルールを配布先のポリシー管理ルールから消去する。

ステップ２５０７では、ポリシー管理ルールへの処理内容がポリシー管理ルールの変更の場合であるかどうかを調べ、変更である場合にはステップ２５０８へ進む。ステップ２５０８では、変更されたポリシー管理ルールを配布先へ上書き配布する（配布先のポリシー管理ルールと入れ替える）。

ステップ２５０９では、他ドメインのポリシー管理処理部へ、ポリシー管理ルールを配布する。

次に、本実施形態のプログラム配置システムにおいて、業務ＡＰの構成管理情報とリソースの構成管理情報とを関連付けにより、起動時の業務ＡＰの稼働条件に適したリソースを選択する実行制御について説明する。

本実施形態のプライベートドメイン管理サーバ１１の実行管理処理部４５は、業務ＡＰ４８の実行要求を受信して業務ＡＰ４８で使用されるリソースの予約を指示し、前記指示によって予約の行われたリソースで業務ＡＰ４８を起動する処理を行う。また空間スケジューラ４４は、前記予約指示の行われた業務ＡＰ４８に関連付けられたリソースの構成管理情報が業務ＡＰ４８の構成管理情報中の稼働条件を満たす場合に、その業務ＡＰ４８を実行するリソースとして前記リソースを予約する処理を行う。

そして配布管理処理部４３は、前記起動される業務ＡＰ４８やＤＢ管理システム等のプログラムを、前記予約されたリソースに該当するリアル業務サーバ４９へ配布する処理を行う。

図２６は本実施形態の業務ＡＰ起動時の実行管理処理の処理内容を示す図である。ステップ２６０１でプライベートドメイン管理サーバ１１の実行管理処理部４５は、業務ＡＰの実行要求を受信したかどうかを調べ、受信した場合にはステップ２６０２へ進む。

ステップ２６０２では、空間スケジューラ４４へリソース予約処理を行い、ステップ２６０３では、ステップ２６０２の処理によりリソースが予約できたかどうかを調べ、予約できた場合にはステップ２６０４へ進み、そうでない場合にはステップ２６０８へ進む。

ステップ２６０４では、空間スケジューラ４４から業務実行サーバ名と業務ＡＰ開始予定時刻を入力し、ステップ２６０５では、入力した業務実行サーバで業務ＡＰを開始予定時刻に実行するスケジュール予約情報を生成して、ステップ２６０６では、業務ＡＰ開始時刻２５８を記録し、ステップ２６０７では、業務ＡＰ終了後、業務ＡＰ終了時刻２５９を記録する。

ステップ２６０８では、その業務ＡＰを実行可能な業務実行サーバが無いことを示す応答を行い、リトライを指示する。

図２７は本実施形態のリソースのスケジュール予約のイメージを示す図である。図２７に示す様に本実施形態ではリソースのスケジュール予約を行う。

図２８は本実施形態のプライベートドメイン２の空間スケジューラ４４の処理内容を示す図である。ステップ２８０１では、構成管理処理部４１へ業務ＡＰ単位のリソース使用状態を確認する処理を行う。

ステップ２８０２では、受信した事象の内容を調べ、リソース予約の通知を受信した場合にはステップ２８０３へ進み、リソース異常の通知を受信した場合にはステップ２８０６へ進み、未使用サーバの通知を受信した場合にはステップ２８０８へ進み、ポリシー管理ルールの通知を受信した場合にはステップ２８１０へ進む。

ステップ２８０３では、実行管理からリソース予約の内容を受信し、ステップ２８０４で業務ＡＰ実行サーバの確認処理を実行し、ステップ２８０５でリソーススケジュール予約処理を実行する。

ステップ２８０６では、構成管理からリソース異常の内容を受信し、ステップ２８０７では、業務ＡＰの特定と対処処理を実行する。

ステップ２８０８では、構成管理から未使用サーバの識別情報を受信し、ステップ２８０９では、余剰サーバの判定処理を実行する。

ステップ２８１０では、空間スケジューラ用のポリシー管理ルールを入力して反映する。

図２９は本実施形態の業務ＡＰ実行サーバの確認処理の処理内容を示す図である。ステップ２９０１では、指定された業務ＡＰ実行サーバ名２２３のサーバのＯＳ情報３１２のユーザ名７０１に指定された業務ＡＰ実行ユーザ名２２４は存在するかどうかを調べ、存在する場合にはステップ２９０２へ進む。

ステップ２９０２では、指定された業務ＡＰのＡＰ稼動条件２１２に指定されたデータパス名２３２〜使用ＤＢ名２４２のリソースが指定された業務ＡＰ実行サーバ名２２３のサーバに空きリソースとして存在するかどうかを調べ、存在しない場合にはステップ２９０３へ進む。
ステップ２９０３では、業務実行サーバの変更処理を実行する。

ステップ２９０４では、フラグが「０」であるかどうかを調べ、フラグが「０」である場合にはステップ２９０５へ進む。ステップ２９０５では、論理ホストの確認処理を行う。

図３０は本実施形態の業務実行サーバの変更処理の処理内容を示す図である。ステップ３００１では、該当サーバが無いことを示すフラグ１に「１」を設定し、ステップ３００２では、フラグが「１」である間、他のサーバ名３３０の数だけループする処理を行う。

ステップ３００３では、指定された業務ＡＰのＡＰ稼動条件２１２に指定されたデータパス名２３２〜使用ＤＢ名２４２のリソースが他のサーバ名のＯＳ情報に存在するかどうかを調べ、存在する場合にはステップ３００４へ進む。

ステップ３００４では、該当したサーバのＯＳ情報３１２のユーザ名７０１に指定された業務ＡＰ実行ユーザ名２２４は存在するかどうかを調べ、存在する場合にはステップ３００５へ進む。

ステップ３００５では、フラグに「０」を設定し、ステップ３００６では、該当サーバ名を業務ＡＰ実行サーバ名２２３に設定して、該当のサーバを業務実行サーバに選択する。

ステップ３００７では、フラグが「１」であるかどうかを調べ、フラグが「１」である場合にはステップ３００８へ進む。ステップ３００８では、パブリックドメインの空間スケジューラ３４へ、指定された業務ＡＰのＡＰ稼動条件に合致するサーバの提供を要求する。

図３１は本実施形態の論理ホストの確認処理の処理内容を示す図である。ステップ３１０１では、指定された業務ＡＰの論理ホスト名２３９を取得する。

ステップ３１０２では、指定されたサーバ名３３０の論理ホスト名３７０〜３７２に論理ホスト名２３９と一致するものがあるかどうかを調べ、一致するものが無い場合にはステップ３１０３へ進む。

ステップ３１０３では、他のサーバ名のＯＳ情報３１２の論理ホスト名３７０〜３７２に論理ホスト名２３９と一致するものがあるかどうかを調べ、一致するものがある場合にはステップ３１０４へ進む。

ステップ３１０４では、他のサーバ名のＯＳから一致した論理ホスト名２３９を削除し、ステップ３１０５では、業務実行サーバのＯＳに論理ホスト名２３９を生成する。

図３２は本実施形態のリソーススケジュール予約処理の処理内容を示す図である。ステップ３２０１では、フラグが「０」であるかどうかを調べ、フラグが「０」である場合にはステップ３２０２へ進む。

ステップ３２０２では、指定された業務ＡＰの業務ＡＰ時刻指定有無２２５が「有」であるかどうかを調べ、「有」である場合にはステップ３２０３へ進み、そうでない場合にはステップ３２０６へ進む。

ステップ３２０３では、空間スケジューラ４４に指定された業務ＡＰのＡＰ稼動条件２１２に指定されたデータパス２３２〜ディスク容量２３８までのリソースに空きはあるかどうかを調べ、ある場合にはステップ３２０４へ進み、そうでない場合にはステップ３２０５へ進む。

ステップ３２０４では、空間スケジューラ４４にリソースを時刻指定で予約し、またステップ３２０５では、フラグにスケジュール不可であることを示す「２」を設定する。

またステップ３２０６では、空間スケジューラ４４にリソース予約時間無期限でリソースを予約する。

次に、本実施形態のプログラム配置システムにおいて、業務ＡＰの構成管理情報とリソースの構成管理情報とを関連付けにより、稼働中の業務ＡＰの稼働条件に適したリソースを選択してクラスタリングを行う実行制御について説明する。

本実施形態のプライベートドメイン管理サーバ１１の実行管理処理部４５は、業務ＡＰ４８を実行中のリソースに異常が検出された場合に、前記リソース異常の発生した業務ＡＰ４８の構成管理情報中の稼働条件を満たす構成管理情報を持つ他のリソースを検索し、その検索されたリソースで業務ＡＰ４８の処理を続行する処理を行う。そして配布管理処理部４３は、リソース異常となった業務ＡＰ４８やＤＢ管理システム等のプログラムを、前記検索されたリソースのリアル業務サーバ４９へ配布する。

図３３は本実施形態の業務ＡＰの特定と対処を行う処理内容を示す図である。ステップ３３０１では、リソース異常の発生した業務サーバを特定し、ステップ３３０２では、該当サーバで稼動中の業務ＡＰの一覧を作成する。

ステップ３３０３では、どこのリソース異常であるかを調べ、サーバの異常である場合にはステップ３３０４へ進み、ＤＢの異常である場合にはステップ３３０５へ進み、ストレージの異常である場合にはステップ３３０８へ進む。

ステップ３３０４では、業務ＡＰのクラスタリング処理を行う。
ステップ３３０５では、ＤＢの回復処理を行い、ステップ３３０６では、前記回復処理によりＤＢ異常は取り除けたかどうかを調べ、取り除けない場合にはステップ３３０７で業務ＡＰのクラスタリング処理を行う。
またステップ３３０８では、ストレージ論理ユニットの容量の追加を行う。

図３４は本実施形態の業務ＡＰのクラスタリング処理の処理内容を示す図である。ステップ３４０１では、フラグに「０」を設定し、ステップ３４０２では、業務ＡＰの一覧からクラスタリング可否フラグ２４０が可の業務ＡＰを抽出し、かつ業務ＡＰ重要度の低い順番に一覧を作成する。
ステップ３４０３では、フラグが「０」である間、抽出した業務ＡＰの数だけループする処理を行い、ステップ３４０４では、フラグが「０」である間、業務ＡＰ名５１０の数分ループする処理を行う。

ステップ３４０５では、抽出した業務ＡＰと一致する業務ＡＰ名はあるかどうかを調べ、一致するものがある場合にはステップ３４０６へ進む。ステップ３４０６では、クラスタリングサーバ名の確認処理を実行する。

図３５は本実施形態のクラスタリングサーバ名の確認処理の処理内容を示す図である。ステップ３５０１では、該当サーバと一致しない稼動サーバ名はあるかどうかを調べ、ある場合にはステップ３５０２へ進む。

ステップ３５０２では、一致しなかった稼動サーバ名のＯＳ情報３１２のリソースに抽出した業務ＡＰのＡＰ稼動条件２１２の空きがあるかどうかを調べ、空きがある場合にはステップ３５０３へ進む。

ステップ３５０３では、フラグ１に「１」を設定し、ステップ３５０４では、該当稼動サーバへクラスタリングする指示をクラスタ／データパス管理へ要求する。

次に、本実施形態のプログラム配置システムにおいて、プライベートドメイン及びパブリックドメインにより余剰リソースを管理し、業務ＡＰの起動時またはリソース異常時に稼働条件に適した余剰リソースを提供する処理について説明する。

図３６は本実施形態の余剰サーバの判定処理の処理内容を示す図である。図３６に示す様にプライベートドメイン管理サーバ１１の空間スケジューラ４４は、余剰リソースを判定する処理を行う。

ステップ３６０１では、未使用サーバの入力を行い、ステップ３６０２では、空間スケジューラのポリシーを入力する。

ステップ３６０３では、未使用サーバはマシン使用形態２３１が専用の業務ＡＰが稼動する業務サーバかどうかを調べ、専用の業務ＡＰが稼動する業務サーバである場合にはステップ３６０４へ進み、そのサーバを余剰サーバとはせずに呼び出し元へ戻る。

ステップ３６０５では、リソース予約の内容を読み出し、ステップ３６０６では、そのサーバのリソース予約があるかどうかを調べ、リソース予約がある場合にはステップ３６０７へ進み、リソース予約が無い場合にはステップ３６０８へ進む。

ステップ３６０７では、リソース予約の確認処理を実行する。またステップ３６０８では、余剰サーバと判定し、ステップ３６０９では、パブリックドメインの空間スケジューラへその構成管理情報を余剰サーバの情報として提供する。

図３７は本実施形態のリソース予約の確認処理の処理内容を示す図である。ステップ３７０１では、リソース予約まで１時間以上あるかどうかを調べ、１時間以上ある場合にはステップ３７０２へ進む。

ステップ３７０２では、余剰サーバと判定し、ステップ３７０３では、構成管理処理部４１へリソース予約時刻までの間を余剰サーバとして提供する。

ステップ３７０４では、リソース予約時間は無期限かどうかを調べ、無期限である場合にはステップ３７０５へ進む。

ステップ３７０５では、該当業務ＡＰのＡＰ稼動履歴を参照し、ステップ３７０６では、該当業務ＡＰの業務ＡＰ終了時刻は記録されているかどうかを調べ、業務ＡＰ終了時刻が記録されている場合にはステップ３７０７へ進む。そしてステップ３７０７では、該当業務ＡＰのリソース予約を解除する。

図３８は本実施形態のプライベートドメイン２の構成管理処理部４１の処理内容を示す図である。ステップ３８０１では、管理情報の関連付け処理を実行する。

ステップ３８０２では、事象の受信し、ステップ３８０３では、受信した事象の内容を調べ、受信した事象が管理情報の取得要求である場合にはステップ３８０４へ進み、サーバの返却である場合にはステップ３８０６へ進み、リソース異常である場合にはステップ３８０７へ進み、未使用サーバである場合にはステップ３８１０へ進み、余剰サーバである場合にはステップ３８１１へ進み、ポリシー管理ルールである場合にはステップ３８１３へ進む。

ステップ３８０４では、管理情報要求の受信処理を実行し、ステップ３８０５では、管理情報を要求元へ応答する。
ステップ３８０６では、返却されたサーバの構成情報のパブリックドメインへの公開を停止する。

ステップ３８０７では、性能・容量から受信した異常なリソースはパブリックドメインへ提供済みかどうかを調べ、提供済みである場合にはステップ３８０８へ進み、そうでない場合にはステップ３８０８へ進む。

ステップ３８０８では、リソース異常をパブリックドメインの構成管理処理部３１へ通知し、またステップ３８０９では、リソース異常を空間スケジューラ４４とクラスタ／データパス管理へ通知する。

ステップ３８１０では、未使用サーバを空間スケジューラへ通知する。
ステップ３８１１では、余剰サーバをパブリックドメインの構成管理へ通知し、ステップ３８１２では、余剰サーバの管理情報をパブリックドメインの構成管理処理部３１へ公開する。
ステップ３８１３では、ポリシー管理ルールを受信してＡＣＬの設定と安全係数を設定する。

図３９は本実施形態の管理情報要求受信処理の処理内容を示す図である。ステップ３９０１では、要求された管理情報の内容を調べ、要求された管理情報がＡＰ稼働状況である場合にはステップ３９０２へ進み、ＡＰ稼働条件である場合にはステップ３９０３へ進み、ＤＢ情報である場合にはステップ３９０４へ進み、クラスタ／データパス情報である場合にはステップ３９０５へ進み、その他の情報である場合にはステップ３９０７へ進む。

ステップ３９０２では、ＡＰ稼動状況２１１の業務ＡＰ状態以外の情報について、運用者の設定値を取得し、ステップ３９０３では、ＡＰ稼動条件２１２について運用者の設定値を取得する。

またステップ３９０４では、ＤＢから情報を取得し、ステップ３９０５では、クラス管理プログラムから情報を取得し、ステップ３９０６では、データパス管理プログラムからデータパス情報を取得し、ステップ３９０７では、性能・容量管理から情報を取得する。

本実施形態のパブリックドメイン管理サーバ２１の構成管理処理部３１は、余剰リソースを検出する為のルールに該当するリソースの構成管理情報をプライベートドメイン２側の構成管理処理部４１から受信し、パブリックドメイン１中の仮想リソース３８の構成管理情報として維持管理する処理を行う。

図４０は本実施形態のパブリックドメイン１の構成管理処理部３１の処理内容を示す図である。ステップ４００１では、事象の受信し、ステップ４００２では、受信した事象を調べ、受信した事象が余剰サーバである場合にはステップ４００３へ進み、サーバの返却である場合にはステップ４００５へ進み、ポリシー管理ルールである場合にはステップ４００８へ進む。

ステップ４００３では、受信した余剰サーバの構成情報をプライベートドメインの構成管理から取得する。
ステップ４００４では、余剰サーバを空間スケジューラ３４へ通知し、ステップ４００５では、空間スケジューラ３４からサーバの返却を受信し、ステップ４００６では、返却されたサーバを提供されたプライベートドメインへ返却する。またステップ４００７では、返却されたサーバの構成情報を削除し、ステップ４００８では、ポリシー管理ルールを受信して設定する。

本実施形態のパブリックドメイン管理サーバ２１の空間スケジューラ３４は、業務ＡＰ４８の稼働条件を満たす構成管理情報を持つリソースが見つからない場合に送信されたリソースの提供要求をプライベートドメイン２側の空間スケジューラ４４から受信し、前記維持管理している仮想リソースの構成管理情報の内で業務ＡＰ４８の稼働条件を満たす構成管理情報を送信する処理を行う。

図４１は本実施形態のパブリックドメイン１の空間スケジューラ３４の処理内容を示す図である。ステップ４１０１では、構成管理処理部３１から余剰サーバを取得する。

ステップ４１０２では、プライベートドメインの空間スケジューラ４４からのサーバ提供要求を受信し、ステップ４１０３では、要求されたプライベートドメインから提供された余剰サーバがあるかどうかを調べ、ある場合にはステップ４１０４へ進み、そうでない場合にはステップ４１０５へ進む。

ステップ４１０４では、該当する余剰サーバを貸し出し、ステップ４１０５では、他のプライベートドメインから提供された余剰サーバがあるかどうかを調べ、ある場合にはステップ４１０６へ進み、そうでない場合にはステップ４１０７へ進む。そしてステップ４１０６では、その余剰サーバを貸出し、またステップ４１０７では、貸出しサーバ無しを応答する。

ステップ４１０８では、プライベートドメインの空間スケジューラ４４から貸し出していたサーバの返却を受信し、ステップ４１０９では、パブリックドメインの構成管理処理部３１へサーバの返却を通知する。
またステップ４１１０では、ポリシー管理ルールを受信して設定する。

図４２は本実施形態のプライベートドメイン２の性能・容量管理処理部４７の処理内容を示す図である。図４２に示す様にプライベートドメイン管理サーバ１１の性能・容量管理処理部４７は、各サーバ４９の性能やストレージ５０の容量等に関する状態を示す管理情報を収集して管理する処理を行う。

ステップ４２０１では、事象の受信を行い、ステップ４２０２では、受信した事象を調べ、受信した事象が管理情報の取得要求である場合にはステップ４２０３へ進み、ポリシー管理ルールである場合にはステップ４２０４へ進み、リソース監視である場合にはステップ４２０５へ進み、その他の事象である場合にはステップ４２１１へ進む。

ステップ４２０３では、要求された管理情報を業務ＡＰ４８，サーバ４９，ストレージ５０から取得して応答する。またステップ４２０４では、ポリシー管理ルールを受信して設定する。

ステップ４２０５では、履歴の保存を行い、ステップ４２０６では、リソースの使用率が９５％を超えたリソースはあるかどうかを調べ、ある場合にはステップ４２０７へ進む。このリソース使用率の95％という値は、ポリシー管理ルールにより変更できる。

ステップ４２０７では、該当リソースを調べ、該当リソースがサーバである場合にはステップ４２０８へ進み、ストレージである場合にはステップ４２０９へ進み、ＤＢである場合にはステップ４２１０へ進む。

ステップ４２０８では、構成管理処理部４１へサーバのリソース異常を通知し、またステップ４２０９では、構成管理処理部４１へストレージ容量不足のリソース異常を通知し、ステップ４２１０では、構成管理処理部４１へＤＢのリソース異常を通知する。
またステップ４２１１では、定期間隔にリソース監視事象を送信する。

図４３は本実施形態のプライベートドメイン２のクラスタ／データパス管理処理部４６の処理内容を示す図である。図４３に示す様にプライベートドメイン管理サーバ１１のクラスタ／データパス管理処理部４６は、クラス管理プログラムの構成や状態の管理と、データパス管理プログラムが持つサーバ４９とストレージ５０間のデータパスの構成や状態及びデータパスの変更指示を管理する処理を行う。

ステップ４３０１では、事象の受信を行い、ステップ４３０２では、受信した事象を調べ、受信した事象が情報取得である場合にはステップ４３０３へ進み、クラスタリング要求である場合にはステップ４３０４へ進み、ポリシー管理ルールである場合にはステップ４３０９へ進む。

ステップ４３０３では、要求された情報を応答する。
ステップ４３０４では、空間スケジューラからクラスタリング要求を受信し、ステップ４３０５では、現在の業務ＡＰ実行サーバ名とクラスタリング先の業務ＡＰ実行サーバ名を取得する。

ステップ４３０６では、ＤＢの変更処理を実行し、ステップ４３０７では、データパスの変更処理を実行する。またステップ４３０８では、クラスタリング先の業務ＡＰ実行サーバで業務ＡＰを起動する。
ステップ４３０９では、ポリシー管理ルールを受信して設定する。

図４４は本実施形態のＤＢ変更処理の処理内容を示す図である。ステップ４４０１では、クラスタリング先の業務ＡＰ実行サーバに該当業務ＡＰ名２２０が使用する使用ＤＢは存在するかどうかを調べ、存在する場合にはステップ４４０２へ進む。

ステップ４４０２では、該当ＤＢは稼動しているかどうかを調べ、稼働していない場合にはステップ４４０３へ進み、ステップ４４０３では、該当ＤＢを起動する。

ステップ４４０４では、該当ＤＢをプライベートドメイン管理サーバからクラスタリング先の業務ＡＰ実行サーバへ配布し、ステップ４４０５では、該当ＤＢを起動する。

図４５は本実施形態のデータパス変更処理の処理内容を示す図である。ステップ４５０１では、クラスタリング先の業務ＡＰ実行サーバから、該当業務ＡＰ名２２０が使用するストレージ論理ユニットは参照できるかどうか（データパスはあるかどうか）を調べ、参照できる場合にはステップ４５０２へ進む。

ステップ４５０２では、該当ＤＢからストレージ論理ユニットは参照できるかどうかを調べ、参照できない場合にはステップ４５０３へ進む。ステップ４５０３では、ＤＢからストレージ論理ユニットを参照できるようにＤＢの設定を変更する。

ステップ４５０４では、データパス管理からストレージ論理ユニットを参照できるようにデータパスの設定を変更する。ステップ４５０５では、該当ＤＢからストレージ論理ユニットは参照できるかどうかを調べ、参照できない場合にはステップ４５０６へ進む。ステップ４５０６では、ＤＢからストレージ論理ユニットを参照できるようにＤＢの設定を変更する。

次に、本実施形態のプログラム配置システムにおいて、リソースの稼働状態の変化を予測し、ポリシー管理ルールを変更する処理について説明する。

図４６は本実施形態の予測結果を反映するポリシー管理処理の処理内容を示す図である。ステップ４６０１では、業務ＡＰ単位、サーバ単位、リソース単位にリソース使用の上限の初期値を入力する。

ステップ４６０２では、構成管理情報の入力を行い、ステップ４６０３では、リソース使用上限を越えた業務ＡＰ、サーバまたはストレージが存在するかどうかを調べ、存在する場合にはステップ４６０４へ進む。

ステップ４６０４では、リソース使用上限の補正処理を実行する。ステップ４６０５では、該当業務ＡＰのポリシー管理ルールは存在するかどうかを調べ、存在する場合にはステップ４６０６へ進み、そうでない場合にはステップ４６０７へ進む。

ステップ４６０６では、業務ＡＰのポリシー管理ルールの上限値の変更を行い、またステップ４６０７では、該当業務ＡＰのポリシー管理ルールを登録する処理を行う。

ステップ４６０８では、リソース使用傾向の予測処理を実行し、ステップ４６０９では、リソース管理ルールの配布処理を行う。

図４７は本実施形態のマシン及び業務ＡＰ単位のリソース使用状況把握例を示す図である。図４７に示す様に本実施形態では、履歴情報からリソース使用状況を表示し、マシン及び業務ＡＰ単位でのリソース使用状況の把握を行う。

図４８は本実施形態のマシン及び業務ＡＰ単位のリソース許容範囲例を示す図である。図４８に示す様に本実施形態ではマシン及び業務ＡＰ単位でリソース使用率からリソース許容範囲を求め、その許容範囲から上限値を設定する。

図４９は本実施形態のマシン及び業務ＡＰ単位のリソース使用上限値の補正例を示す図である。図４９に示す様に本実施形態では、履歴情報の変動から長期的な変動傾向を図の「傾き」の様に求め、マシン及び業務ＡＰ単位でのリソース使用上限値の補正に用いる。

図５０は本実施形態のリソース使用上限値補正処理の処理内容を示す図である。ステップ５００１では、該当業務ＡＰのＡＰ稼働履歴（図８）の入力を行い、ステップ５００２では、安定稼働の上限値の算出（図４８）を行う。

ステップ５００３では、リソースの項目分ループさせる処理を行って、ステップ５００４では、異常は発生したかどうかを調べ、発生した場合にはステップ５００５へ進む。

ステップ５００５では、異常発生時のリソース使用率の入力を行い、ステップ５００６では、異常発生時のリソース使用率での該当業務ＡＰの最新履歴での業務ＡＰ終了状態は正常終了かどうかを調べ、正常終了した場合にはステップ５００７へ進む。

ステップ５００７では、該当業務ＡＰのリソース使用の上限値の補正（図４８の例、メモリの安定稼働の上限値を４５％から６５％に補正）
図５１は本実施形態のリソース使用傾向予測処理の処理内容を示す図である。ステップ５１０１では、サーバリソース及びストレージリソース分ループさせる処理を行い、ステップ５１０２では、リソース使用率が増加傾向にあるリソースはあるかどうかを調べ、ある場合にはステップ５１０３へ進む。

ステップ５１０３では、将来時刻に対するリソース使用率の傾きを算出して、
計算式（将来のリソース使用率）＝（最新値）×傾き×（将来時刻−現在時刻）
を作成し、ステップ５１０４では、予測値の反映処理を行う。

図５２は本実施形態の予測値反映処理の処理内容を示す図である。ステップ５２０１では、次回履歴時刻にリソース使用率がアクション境界値を越えるかどうかを調べ、越える場合にはステップ５２０２へ進む。

ステップ５２０２では、現在のリソース使用率はアクション境界値を越えるかどうかを調べ、越える場合にはステップ５２０３へ進み、そうでない場合にはステップ５２０５へ進む。

ステップ５２０３では、該当リソース上で動作する業務ＡＰに異常は発生しているかどうかを調べ、異常は発生していない場合にはステップ５２０４へ進む。

ステップ５２０４では、該当リソースのポリシー管理ルールのアクション境界値を現在のリソース利用率に変更する。またステップ５２０５では、該当リソースのポリシー管理ルールのアクション境界値を現在のリソース利用率に変更する。

なお前記アクション境界値は、別途実験やシミュレーション等により求められた、異常が発生するリソース使用率であるものとする。

以上説明した様に本実施形態のプログラム配置システムによれば、業務アプリケーションの構成管理情報とリソースの構成管理情報とを関連付けた業務アプリケーション情報を生成して、業務アプリケーション単位で使用リソースを管理するので、各業務アプリケーションの稼働条件に合わせてリソースの管理を行うことが可能である。

１…パブリックドメイン、２…プライベートドメイン、３…ネットワーク、１０…リアル業務サーバ群、１１…プライベートドメイン管理サーバ、１２…プライベートドメイン構成情報、１３…リアルストレージ、２０…仮想業務サーバ群、２１…パブリックドメイン管理サーバ、２２…パブリックドメイン構成情報、２３…仮想ストレージ、３８…仮想リソース、４８…業務ＡＰ、４９…サーバ、５０…ストレージ、３０…運用監視処理部、３１…構成管理処理部、３２…ポリシー管理処理部、３４…空間スケジューラ、４０…運用監視処理部、４１…構成管理処理部、４２…ポリシー管理処理部、４３…配布管理処理部、４４…空間スケジューラ、４５…実行管理処理部、４６…クラスタ／データパス管理処理部、４７…性能・容量管理処理部、７０…業務ＡＰ、７１…Ｗｅｂアプリケーション、７２…バッチジョブ、７３…ワークフロー、８０…サーバ、８１…ＤＢ管理処理部、８２…クラスタ／データパス管理処理部、８３…ＯＳ、９０…ストレージ、２２８…業務ＡＰ重要度、２５８…業務ＡＰ開始時刻、２５９…業務ＡＰ終了時刻、３５２…最大メモリ量、３５３…使用メモリ量、３５４…残メモリ量、３５７…残プロセス数、３６０…残スレッド数、３６５…残ディスク容量。

Claims (4)

1. パブリックドメイン管理サーバと仮想リソースとからなるパブリックドメインと、プライベートドメイン管理サーバと業務を実行するリアル業務サーバと業務で用いられるデータを格納するリアルストレージとからなるプライベートドメインが複数ある業務管理システムにおける業務リソース管理方法であって、
   前記プライベートドメイン管理サーバは、余剰リソースがある場合に余剰リソースがあることを前記パブリックドメインへ通知し、
   前記パブリックドメイン管理サーバは、前記余剰リソースを仮想リソースとして対応付け、
   前記パブリックドメイン管理サーバは、前記プライベートドメイン管理サーバからのリソース提供要求を受け、
   要求元の前記プライベートドメインに提供できる仮想リソースがあるかを判断し、
   前記仮想リソースがある場合には、前記仮想リソースに対応する前記余剰リソースを要求元である前記プライベートドメインへ貸し出す通知をする業務リソース管理方法において、
   前記余剰リソースがある場合であって、該余剰リソースが要求元であるプライベートドメインから提供された余剰リソースである場合には該余剰リソースを貸し出し、
   要求元のプライベートドメインから提供された余剰リソースが無い場合には他のプライベートドメインから提供された余剰リソースを貸し出すことを特徴とする業務リソース管理方法。
2. 請求項１において、前記プライベートドメイン管理サーバは、マシンの使用形態とリソース予約の状態に基づいてリソースが前記余剰リソースであるかを判定することを特徴とする業務リソース管理方法。
3. パブリックドメイン管理サーバと仮想リソースとからなるパブリックドメインと、プライベートドメイン管理サーバと業務を実行するリアル業務サーバと業務で用いられるデータを格納するリアルストレージとからなるプライベートドメインが複数ある業務管理システムであって、
   前記プライベートドメイン管理サーバは、余剰リソースがある場合に余剰リソースがあることを前記パブリックドメインへ通知する第１の構成管理処理部を備え、
   前記パブリックドメイン管理サーバは、前記余剰リソースを仮想リソースとして対応付ける第２の構成管理処理部と、前記プライベートドメイン管理サーバからのリソース提供要求を受け、要求元の前記プライベートドメインに提供できる仮想リソースがあるかを判断し、前記仮想リソースがある場合には、前記仮想リソースに対応する前記余剰リソースを要求元である前記プライベートドメインへ貸し出す通知をする手段とを備える業務管理システムにおいて、
   前記手段は、前記余剰リソースがある場合であって、該余剰リソースが要求元であるプライベートドメインから提供された余剰リソースである場合には該余剰リソースを貸し出し、要求元のプライベートドメインから提供された余剰リソースが無い場合には他のプライベートドメインから提供された余剰リソースを貸し出すものであることを特徴とする業務管理システム。
4. 請求項３において、前記プライベートドメイン管理サーバは、マシンの使用形態とリソース予約の状態に基づいてリソースが前記余剰リソースであるかを判定する手段を備えることを特徴とする業務管理システム。

Images