JP4605036B2 - 計算機システム、管理サーバ、計算機設定時間を低減する方法およびプログラム - Google Patents

Description

本発明は、計算機システム、計算機設定時間を低減する方法、および計算機設定時間を低減するための計算機設定時間を低減するプログラムに関し、特に、計算機設定に複数の手順が必要な状況において計算機設定時間を低減することができる計算機システム、計算機設定時間を低減する方法および計算機設定時間を低減するためのプログラムに関する。

計算機を利用したサービスを提供する企業では、サービス要求の増大に対応するために、最大要求に耐えうるだけのソフトウェアや計算機を保持する必要がある。しかし、最大要求に耐えうるだけのソフトウェアや計算機を保持するには、固定費がかさむという問題がある。この問題を改善するために、急激なサービス要求の増大があった場合に、ソフトウェアや計算機などの必要なリソースを一時的に追加できることが好ましい。そこで、近年、固定費の削減や急激なサービス要求の増大への対処を目的として、計算機を利用したサービスやソフトウェア、計算機などを必要に応じて契約し利用するユーティリティコンピューティングが注目されている。

サービス要求量が時間によって大きく変化するサービスがあるので、ユーティリティコンピューティングにおいては、急激なサービス要求の増大に対応することが求められている。例えば、野球中継などの特定のイベント用のウェブページ提供サービスでは、イベントが開始される前に比べ、イベントが開始されると急激にサービス要求量が増加する。急激なサービス要求量増加に対応できなければ、ウェブページの提供を受ける一般ユーザの満足度の低下を招き、一般ユーザの減少に繋がるおそれがある。

急激なサービス要求量の増加に対応するために、サービス要求量が増加したときに、計算機数などのリソース量を増加させる必要がある。例えば、サービス要求量に比例した数だけ計算機が必要な場合には、サービス要求量が増加した場合には、それに比例させて計算機の数も増加させる必要がある。

ここで問題になるのは、計算機の設定に時間がかかるため、サービス要求量の増加に素早く対応できないことである。計算機の設定では、例えばＯＳ（Operating System）のインストール、ＯＳの設定、ミドルウェアのインストール、ミドルウェアの設定、アプリケーションのインストール、アプリケーションの設定、アプリケーションの起動、データのコピーなどの操作が必要になる。これらの操作を全て実施するには数時間かかる可能性がある。そのため、サービス要求量が増加してからこれらの操作を実施したのでは、多くのサービスにとってサービス要求量の増加に対応することはできない。

この問題に対処するために、２つの方法が用いられている。一つ目の方法は、計算機の設定を行なっておき、短時間でサービスに対応できる状態（ホットスタンバイ）に計算機を維持しておく方法である。二つ目の方法は、サービスの要求量の増加を事前に予測し、予測された要求量に合わせて、事前に計算機の設定を行なう方法である。一つ目の方法には、以下のような問題点がある。

ホットスタンバイとは、サービスを提供している計算機と同様の状態、またはその状態にある計算機を意味する。ホットスタンバイの状態にある計算機の特徴として、非常に短時間でサービス向けの設定を終えることができることが挙げられる。

ホットスタンバイの問題は、対象とするサービスが多いときには、多くの待機計算機が必要になることである。ホットスタンバイを用いるシステムでは、対象とするサービス毎に計算機を必要なだけ用意しておく。そのため、対象サービスの数に比例した数の待機計算機を用意する必要がある。対象となるサービス数が多くなった場合には、必要な待機計算機数が多くなり、その分、計算機にかかるコストが大きくなってしまう。そのため、ユーティリティコンピューティングの目的である固定費の削減が達成できなくなる。また、全ての待機計算機を、可能な限り特定のサービス向けにホットスタンバイとすることも考えられる。しかしその場合には、ホットスタンバイが用意されていないサービスの利用要求を受け取った場合に、他のサービス向けのホットスタンバイに設定し直す時間が長くかかるという問題が生ずる。

また、非特許文献１には、リソースキャッシュと呼ばれる手法を用いて計算機設定時間（以下、計算機リソース設定時間ともいう。）の短縮を図る技術が記載されている。リソースキャッシュとは、サービスを使わなくなった計算機において、ソフトウェアを消さずにすぐに利用できる状態にしておく手法である。また、ソフトウェアをすぐに利用できる状態にある計算機は、キャッシュされている状態にある計算機と呼ばれる。リソースキャッシュにより、サービスの要求が再び増大した場合に、リソースキャッシュされている計算機は、すぐ利用可能な状態に設定される。

リソースキャッシュの問題点として、キャッシュミスしたときのペナルティが大きいことが挙げられる。キャッシュミスとは、キャッシュされているリソースが、すぐに追加できないサービスで必要になることである。キャッシュされているリソースの状態を初期状態に戻すために時間がかかる場合には、リソースの設定時間が非常に大きくなってしまう。この場合にはサービスの要求量の増大に素早く対応することが難しいという問題が生ずる。この問題は、ホットスタンバイの問題と同様である。

また、非特許文献２には、サービスが計算機を利用するために必要なＯＳをあらかじめ準備しておくことと、ＮＦＳ（Network File System ）を用いることによってサービスに必要なデータを初期化時に移さないことによって、ソフトウェア、計算機の準備時間を短縮する手法が記載されている。この手法では、計算機をすぐに追加できる状態にはしていない。

非特許文献２に記載された手法の問題点として、サービスの要求によっては設定時間が十分短かいとはいえない点と、サービスによってはこの手法を用いることができない点が挙げられる。非特許文献２に記載された手法では、個々の設定時間を短かくしているが、その時間でよいのかどうかはサービスの要求に依存する。また、ＮＦＳを用いているため実行時のオーバヘッドが大きく、多くのデータを用いるアプリケーションには向かないことが考えられる。

サービスの要求量の増加を事前に予測し、予測された要求量に合わせて事前に計算機の設定を行なう二つ目の方法に関連する技術として、特許文献１に、サービスの要求量の変化の予測に応じて、計算機をホットスタンバイの状態とアプリケーションが入っていない状態との間で状態を遷移させるシステムが記載されている。特許文献１に記載されたシステムでは、待機系計算機リソースは、少なくともアプリケーションがインストールされていないデッドスタンバイ状態を持ち、デッドスタンバイ状態の計算機リソースを複数サービスや複数ユーザで共有する。その結果、遊休計算機リソースの使用率の向上やサーバ統合を実現し、計算機リソース維持に必要なコストを削減する。また、余剰の出るサービスから遊休計算機リソースを確保し、個々のサービスに関して過去の稼動履歴を用いて負荷予測を行い、予測結果に応じて遊休計算機リソースを投入する。

ここで、デッドスタンバイとは少なくともアプリケーションがインストールされていない状態であって、アプリケーションやＯＳをインストールすることでどのようなサービスの待機系にもなりうる状態である。

しかし、特許文献１ではホットスタンバイおよびデッドスタンバイの状態しか定義していないので、二つの問題点があると考えられる。

１番目の問題点は、遊休計算機リソース数が少ない時に負荷予測に従って全ての遊休計算機リソースをホットスタンバイにしてしまうと、ホットスタンバイの問題と同様の問題が生ずることである。すなわち、負荷予測で多くの計算機リソースが必要となった場合に、計算機リソースが足りなくなることが考えられる。

２番目の問題点は、多くの遊休計算機リソースをデッドスタンバイとして維持した場合、デッドスタンバイからサービス利用可能な状態に設定する時間が長く、負荷予測の誤差が大きくなる可能性があることである。長時間後の負荷状態を予測する際の負荷予測の誤差は、短時間後の負荷状態を予測する際の負荷予測の誤差に比べ大きくなる可能性がある。負荷予測の誤差が大きくなった場合には、サービス要求に対応しきれないという問題や、リソースが無駄になってしまうなどの問題が生ずる。

特開２００５−１４１６０５ カレン・アプリビー（Karen Appleby ）他８名著、オシアーノ エス・エル・エー ベースト マネジメント オブ ア コンピューティング ユーティリティ（Oceano - SLA Based Management of a Computing Utility）、アイ・エフ・アイ・ピー／アイ・イー・イー・イー・インターナショナル・シンポジウム・オン・インテグレイティッド・ネットワーク・マネジメント（IFIP/IEEE International Symposium on Integrated Network Management）、米国、２００１年５月 ミネヨシ・マスダ（Mineyoshi Masuda） 他４名著、ヴィー・ピー・ディー・シー ヴァーチャル プライベート データ センター ア フレキシブル アンド ラピッド ワークロードマネジメント システム（VPDC: Virtual Private Data Center A Flexible and Rapid Workload-Management System ）、アイ・エフ・アイ・ピー／アイ・イー・イー・イー・インターナショナル・シンポジウム・オン・インテグレイティッド・ネットワーク・マネジメント（IFIP/IEEE International Symposium on Integrated Network Management）、米国、２００３年５月

第１の問題点は、従来のホットスタンバイによる設定時間短縮手法を適用した場合には、対象となるサービスが多い状況では、必要な計算機リソース数が増大してしまうことである。その理由は、従来の計算機設定時間短縮手法では、個々のサービス毎にホットスタンバイを用意する必要があるため、設定されるサービスの数に比例して必要な計算機の数が増加してしまうからである。

第２の問題点は、全ての待機計算機を可能な限り特定のサービス向けにホットスタンバイとした場合には、ホットスタンバイが用意されていないサービスの利用要求を受け取った際に、他のサービス向けのホットスタンバイを設定し直す時間が長くかかることである。その理由は、従来の計算機設定時間短縮手法では、ホットスタンバイが用意されていないサービスの利用要求を受け取った場合には、設定を一から行なう必要があり、その分時間が長くなってしまうためである。

第３の問題点は、多くの遊休計算機リソースをデッドスタンバイとして維持した場合には、デッドスタンバイからサービスを利用可能な状態に設定する時間が長く、負荷予測の誤差が大きくなる可能性があることである。その理由は、長時間後の負荷状態を予測する負荷予測の誤差は、短時間後の負荷状態を予測する負荷予測の誤差に比べ大きくなる可能性があるためである。

本発明の目的は、必要な計算機数を抑えながらも、計算機設定時間を短縮することである。本発明の他の目的は、待機計算機数が少ない状況において、計算機リソースの利用要求を受け取った後の計算機設定時間を平均的に短縮することである。本発明のさらに他の目的は、計算機設定時間を短かく保つことによって、負荷予測の誤差を小さくすることである。

本発明のさらに他の目的は、特定の技術に依存しない計算機設定時間短縮手法を提供することである。なお、特定の技術に依存しない計算機設定時間短縮手法を、特定の技術に依存した手法と併用することによっても、従来の手法に比べて計算機設定時間を減らすことが可能である。

本発明による計算機システムは、計算機リソースの設定にかかる時間である設定時間の予測値と計算機リソースの設定手順とを用いて、設定時間の期待値が小さくなる計算機リソースの状態を決定する状態決定手段と、計算機リソースを状態決定手段が決定した状態に設定する状態遷移手段とを備えたことを特徴とする。すなわち、状態遷移時間予測手段が予測した予測時間にもとづいて算出する時間であって複数の計算機リソースのそれぞれがとりうる状態の組み合わせにおける各状態からサービス提供可能状態になるまでに要する時間と所定の指標値との積の和が小さくなる組み合わせを決定する状態決定手段と、それぞれの計算機リソースを、状態決定手段が決定した組み合わせにおける状態に設定する状態遷移手段とを備えたことを特徴とする。なお、設定時間の期待値が小さくなる計算機リソースの状態とは、例えば、上記の従来技術を用いた場合に比べて、設定時間が短くなるように設定された状態であり、一例として、設定時間の期待値を最小化するような計算機リソースの状態である。本発明では、計算機リソースの状態を、ホットスタンバイ状態、デッドスタンバイ状態、さらにそれらの中間状態に維持することにより、計算機リソースの設定時間を平均的に短かくすることができる。

第１の効果は、必要な計算機数を抑えながらも、計算機リソースの設定時間を短縮できることにある。その理由は、遊休計算機数を考慮し、複数のサービスに短かい時間で振り向けられるような状態に設定するからである。状態を決定する際に、計算機の設定時間の予測値を用いて決定することにより、計算機リソースの設定時間を短かくするような、最適な状態を求めることができる。

第２の効果は、待機計算機数が少ない状況において、計算機リソースの設定時間を平均的に短縮できることである。その理由は、計算機リソースを複数のサービスを利用可能な状態にすぐに設定できるような状態に維持することによって、平均的な設定時間を短縮することができるからである。計算機リソースをどのような状態にすればよいかを計算によって求め、計算機リソースをその状態に設定しておく。これにより、ホットスタンバイだけを用いたシステムに比べ、平均的な設定時間を短縮できる。

第３の効果は、サービスの負荷予測に基づいた資源設定を行なう際に、その負荷予測の誤差を小さくできる可能性があることである。その理由は、デッドスタンバイよりも短時間で設定できる状態に計算機リソースを維持することにより、負荷予測を行なう時点をより近い時点にすることができるためである。

以下、本発明を実施するための最良の形態について図面を参照して説明する。

実施の形態１．
第１の実施の形態では、事前に計算機リソースを設定することによって、計算機リソース設定時間を低減する。ここで、計算機リソースの設定には、それに関連するネットワークの設定、アプリケーションの設定、利用者（計算機リソースの要求者）の設定なども含まれる。また、本実施の形態の計算機システムでは、利用されるサービス、およびサービスの設定手順が事前にわかっているとする。また、計算機リソースの設定手順と、計算機リソースの状態遷移をほぼ同様の意味で用いる。詳しくいうと、計算機リソースの設定手順とは、計算機リソース上で特定のサービスを利用可能な状態にする手順を意味する。計算機リソースの状態遷移とは、計算機リソース上の設定が変更され、計算機リソースの状態が変化したことを意味する。また、計算機リソースと資源は、同様の意味を持つとする。計算機リソースまたは資源とは、計算機、ネットワーク、サービスコンポーネントを含む計算機上のソフトウェアコンポーネント等を意味する。

図１は、第１の実施の形態の計算機システムを示すブロック図である。図１に示すように、本発明の第１の実施の形態の計算機システムは、管理サーバ１００と、管理サーバ１００とネットワーク１０１で接続されサービスを提供するための計算を行なう計算機１０２，１０３，１０４とを含む。

図２は、サービスを提供するための計算機の構成を示すブロック図である。なお、図２に示す計算機２００，２１０は、図１に示す計算機１０２，１０３，１０４に相当するものであるが、図２には二つのみが示されているので、付されている符号を、図１において付された符号と変えている。図２において、計算機２００は、ＯＳが既にインストールされている状態のものを示し、計算機２１０は、ＯＳが未だインストールされていない状態のものを示す。

計算機２００は、管理サーバ１００の指示に従って動作するエージェント２０１と、何らかのサービスを提供するサービスコンポーネント２０２とを含む。エージェント２０１は、管理サーバ１００からの指示を受け、計算機２００の状態の取得、サービスコンポーネントの設定、および設定時間の取得を行なう。ただし、計算機２１０のように、計算機にＯＳ（Operating System）が入っていない場合には、エージェントは存在しない。その状況では、管理サーバ１００からＯＳのインストール、エージェントのインストール作業を行なう。

サービスコンポーネント２０２は、各計算機上でサービスを提供する役割を持つ。サービスコンポーネントが複数ある場合もある。サービスコンポーネントは、エージェントからインストール、設定、起動などの操作を受けつける。

図３は、管理サーバ１００の構成を示すブロック図である。管理サーバ１００は、データ処理装置１１０と、記憶装置１２０とを含む。データ処理装置１１０は、開始部１１１、状態決定部１１２、時間予測部１１３、状態取得部１１４および遷移指示部１１５を含む。なお、開始部１１１、状態決定部１１２、時間予測部１１３、状態取得部１１４および遷移指示部１１５は、プログラムとプログラムに従って処理を実行するデータ処理装置１１０のＣＰＵで実現される。また、状態決定部１１２は、設定時間の期待値が小さくなる計算機リソースの状態を決定する状態決定手段の一例であり、遷移指示部１１５は、計算機リソースを状態決定手段が決定した状態に事前設定する状態遷移手段の一例である。時間予測部１１３は、計算機リソースの設定にかかる時間である設定時間を予測し、状態遷移時間の予測値を生成する状態遷移時間予測手段の一例である。

管理サーバ１００における各構成要素はそれぞれつぎのように動作する。
開始部１１１は、資源状態の変更、定期的な資源状態遷移、サービス利用者の要求などを判断し、その判断結果に応じて資源状態決定処理を開始すべきか否か判断する。資源状態決定処理を開始すると判断した場合には、状態決定部１１２にその旨の指示を出す。なお、以下の説明において、サービス利用者とは、計算機リソースを計算機システムに要求して計算機リソースの提供を受ける者を意味する。また、サービスとは、計算機リソースの提供を受けるサービス利用者が、計算機システムの運営者から受けるサービス、例えば、サービス利用者が欲するアプリケーションが使用可能な状態になっている計算機の使用を許可されることを意味する。

状態決定部１１２は、状態決定部１１２から指示を受けると、状態遷移規則ＤＢ（データベース）１２１から取得した状態遷移規則情報、状態決定指標ＤＢ１２２から取得した状態決定指標情報、時間予測部１１３から取得した状態遷移予測時間、および状態取得部１１４から取得した資源の現在の状態をもとに、主に計算機リソースについて、最適な状態を決定する。ここで、最適な状態とは、状態決定指標に従って決定される、資源設定時間の期待値が最小な、または最小に近い状態である。状態決定部１１２で決定された最適な状態は、遷移指示部１１５に渡される。

時間予測部１１３は、状態決定部１１２からの要求を受け、状態遷移時間の予測を行なう。状態遷移時間を予測する方法として、過去の状態遷移履歴から予測する方法、モデル化された状態遷移から予測する方法、部分実行時間から全体の状態遷移時間を予測する方法、またはそれらの方法を組み合わせた方法を用いることができる。

過去の状態遷移履歴から予測する方法とは、過去の状態遷移履歴の平均値から予測時間を算出したり、他の統計学的手法を用いて予測時間を算出する方法である。モデル化された状態遷移から予測する方法とは、計算機の属性を変数とした式として状態遷移をモデル化し、実際の状態をその変数に当てはめることで、予測時間を算出する方法である。部分実行時間から全体の状態遷移時間を予測する方法とは、状態遷移を一部実行し、その実行時間から全体の実行時間を見積り、予測時間を算出する方法である。計算された状態遷移予測時間は、要求元である状態決定部１１２に渡される。

状態取得部１１４は、現在の状態を取得する。現在の状態とは、状態遷移規則上で資源がそのときに位置する状態である。状態取得部１１４が状態を取得するタイミングは、状態取得要求を受け取ってから取得する場合と、状態取得要求を受け取る前にあらかじめ取得しておく場合とが考えられる。状態遷移規則に関する説明は以下で詳述される。

遷移指示部１１５は、計算機を状態決定部１１２が決定した最適な状態にするために、資源の状態を変更したり、変更の指示を各計算機上のエージェント２０１に対して行なう。遷移指示部１１５が行なう変更とは、ＯＳのインストール、エージェント２０１のインストール、サービスコンポーネント２０２の設定指示、その他資源状態の変更である。

次に、図３に示された記憶装置１２０の構成を説明する。記憶装置１２０は、状態遷移規則ＤＢ１２１、状態決定指標ＤＢ１２２、遷移時間履歴ＤＢ１２３を含む。

状態遷移規則ＤＢ１２１は、資源の状態が遷移する規則を保持する。状態遷移規則は、状態の集合と、それぞれの状態を結ぶ枝の集合から構成される。各枝は方向を持っている。ある状態は、枝で示された状態にしか遷移できない。２つの状態間を行き来できる場合には、それらの状態間には互いに逆方向を向いた２つの枝が存在することになる。状態遷移の起点になるのは、各資源に何も設定されていない状態である。例えば、計算機リソースにおいては、ＯＳ、エージェントすら入っていない状態が状態遷移の起点となる。状態遷移規則ＤＢ１２１は、状態決定部１１２に対して、保持している状態遷移規則を渡す。

本実施の形態では、状態遷移規則は、状態遷移規則ＤＢ１２１においてあらかじめ保持されている。状態遷移規則は、例えば、システムの管理者などによって事前に設定される。状態遷移規則の具体例は、第１の実施例において詳述される。また、状態遷移規則の入力を簡易化する手法が、第３の実施の形態で実現される。

次に、状態決定指標ＤＢ１２２について説明する。状態決定指標ＤＢ１２２は、資源状態を決定する際の指標（状態決定指標）を保持する。状態決定指標とは、例えば資源設定要求（サービス利用者が、特定のサービス向けに資源の設定を依頼する要求）の到着確率であったり、サービスの優先度であったり、サービス利用者毎の優先度である。状態決定指標は、状態決定部１１２によって利用される。

遷移時間履歴ＤＢ１２３は、各状態遷移にかかった時間の履歴を保持する。その履歴は、時間予測部１１３によって、状態遷移時間を予測するために用いられる。

次に、図４、図５、図６および図７のフローチャートを参照して本実施の形態の全体の動作について説明する。図４は、状態決定動作の流れを示すフローチャートである。図５は、時間予測部１１３による遷移時間予測動作の流れを示すフローチャートである。図６は、状態取得部１１４による資源状態取得動作の流れを示すフローチャートである。図７は、遷移指示部１１５による状態遷移実行動作の流れを示すフローチャートである。

開始部１１１によって処理が開始されると、すなわち開始部１１１が開始要求を出すと、開始要求を受け取った状態決定部１１２は、状態遷移規則ＤＢ１２１から状態遷移規則を取得する（ステップＡ１）。次に、状態決定部１１２は、状態遷移規則に従って、各状態遷移にかかる時間の予測値を、時間予測部１１３から取得する（ステップＡ２）。開始部１１１は、サービス利用者の端末装置からインターネット等の通信ネットワークを介してサービス利用要求を受けたときに開始要求を状態決定部１１２に出す。

時間予測部１１３の動作を、図５を参照して説明する。時間予測部１１３は、状態決定部１１２からの時間予測要求を受け付ける（ステップＢ１）。時間予測要求を受けた時間予測部１１３は、遷移時間履歴ＤＢ１２３から状態遷移時間の履歴を入力する（ステップＢ２）。そして、入力した状態遷移時間を利用して、状態遷移時間の予測を行なう（ステップＢ３）。予測の方法には、上述したような過去の状態遷移履歴から予測する方法、モデル化された状態遷移から予測する方法、部分実行時間から全体の状態遷移時間を予測する方法、およびそれらの方法を組み合わせた方法の他、様々の方法がある。時間予測部１１３は、求められた状態遷移予測時間を状態決定部１１２に出力する（ステップＢ４）。

状態遷移規則と状態遷移予測時間とを入力した状態決定部１１２は、状態決定指標ＤＢ１２２から状態決定指標を取得する（ステップＡ３）。さらに、状態決定部１１２は、状態取得部１１４から、資源の状態を取得する（ステップＡ４）。

状態取得処理を、図６を参照して説明する。まず、状態取得部１１４は、状態決定部１１２から資源の状態取得要求を受け付ける（ステップＣ１）。次に、状態取得部１１４は、現在の資源の状態を取得する（ステップＣ２）。状態取得部１１４は、資源の状態取得要求を受け取った後に各計算機上のエージェントに資源の状態情報の問い合わせを行ってもよいし、資源の状態取得要求を受け取る前にあらかじめ資源の状態情報を取得しておいてもよい。次に、状態取得部１１４は、取得した資源の状態を状態決定部１１２に出力する（ステップＣ３）。

なお、ステップＡ１の処理はステップＡ２の処理の前に実行されるべきであるが、ステップＡ３の処理およびステップＡ４の処理は、ステップＡ１の処理の前に実行されてもよいし、ステップＡ４の処理の前にステップＡ３の処理が実行されてもよい。

次に、状態決定部１１２は、ステップＡ４で取得した資源の情報を利用して資源の最適な状態を決定する（ステップＡ５）。最適な状態とは、例えば、資源設定時間の期待値を最小化するような状態であったり、サービスや利用者毎に優先度が付けられている場合の優先度に応じた状態などである。また、状態を決定する方法として、考えられる状態の組み合わせ毎に最適かどうかを判断する全探索法を用いてもよいし、全探索法で計算量が多い場合には、組み合わせ最適化手法などを利用してもよい。

その後、状態決定部１１２は、決定された最適な状態を現在の状態と比較し（ステップＡ６）、状態遷移が必要なければそのまま終了する。状態遷移が必要な場合には遷移指示部１１５に状態遷移を依頼する（ステップＡ７）。

遷移指示部１１５の動作を、図７を参照して説明する。遷移指示部１１５は、まず、状態決定部１１２から状態遷移指示を受け付ける（ステップＤ１）。次に、状態遷移を行なう資源を選択し（ステップＤ２）、状態遷移の指示をエージェントに対して行なったり、自ら状態遷移を実行する（ステップＤ３）。その後、状態遷移が成功したか、失敗したかを、状態決定部１１２に通知する（ステップＤ４）。

本実施の形態では、計算機リソースの利用要求を行なう際に、計算機リソースの利用要求者すなわちサービス利用者が資源の選択を行なう。資源選択の指標は、条件に合致する計算機リソースのうち、資源設定時間が十分短かいものであったり、利用する際のコストが低いものであったりする。資源選択の指標が計算機リソースの設定時間である場合を例にすると、計算機リソースの利用要求者は、資源の利用要求を行う前に、まず、利用可能である資源のリストを、利用要求者が有する端末装置等を用いて管理サーバ１００に要求する。管理サーバ１００の資源選択部（図３において図示せず）は、各資源の現在の状態から要求されたサービスを利用要求者に提供可能になるまでの状態に設定するまでに要する計算機リソースの設定時間を、時間予測部１１３に予測させる。そして、時間予測部１１３が予測した計算機リソースの設定時間が短い順に、資源を特定しうる情報例えば資源に付されたＩＤが設定された資源リストを作成する。資源リストは、利用要求者が有する端末装置等に送信される。資源リストには、資源を特定しうる情報の他に、資源の性能および計算機リソースの設定時間も設定される。利用要求者は、資源リストを見て資源を選択し、選択した資源の利用要求を管理サーバ１００に対して行う。一般には、利用要求者は、計算機リソースの設定時間が短い資源を選択する。よって、利用要求者は、短時間でリソースを利用な状態になる。なお、空き資源数が多い場合には、時間予測部１１３による予測に時間がかかり、資源選択にかかる時間が増えることが予想される。これを解決する方法は、第２の実施の形態で実現される。

次に、本実施の形態の効果について説明する。本実施の形態では、状態遷移時間を予測して最適な状態を計算しているので、資源追加要求に対して比較的短い時間で資源追加を行なうことができる。また、非特許文献２ではＮＦＳなどに依存した手法を用いて計算機設定時間の短縮を図っているためサービスの要求によっては用いることができないために計算機設定時間の短縮を図れない場合がある。しかし、本実施の形態では、ＮＦＳなど特定の手法を用いることなく計算機設定時間の短縮を図っているので、汎用性ある計算機設定時間を低減する方法が提供されることになる。

実施の形態２．
次に、本発明の第２の実施の形態について図面を参照して説明する。

本実施の形態では、サービス利用要求を受け取った後の資源選択にかかる時間を低減することを目的として、状態決定部が、資源選択に必要な情報をあらかじめ保存しておく。

図８は、本発明の第２の実施の形態における管理サーバ１００の構成を示すブロック図である。第２の実施の形態でも、管理サーバ１００は、データ処理装置１１０と記憶装置１２０とを含む。ただし、本実施の形態におけるデータ処理装置１１０は、図３に示された第１の実施の形態における構成に加えて、利用要求受付部１１６および資源選択部１１７も備えている。

また、状態決定部１１２の動作は、各資源が短時間で状態遷移可能なサービスの対応付けを保存する点で、第１の実施の形態での動作とは異なる。本実施の形態では、状態決定部１１２は、状態を決定する際に用いる情報をサービスの対応付けとして資源状態管理ＤＢ１２４に保存しておき、この情報は資源選択部１１７に利用される。サービスの対応付けの情報として、例えば、サービスを提供するのに使用可能な資源（計算機リソース）を示す情報と、その資源の設定時間を示す情報との双方を含む情報がある。

利用要求受付部１１６は、サービス利用者からの資源利用要求を受け付ける。資源利用要求とは、サービス利用者が、利用したいサービス、資源量および資源の属性を指定し、利用する資源の選択および設定を依頼することである。利用要求受付部１１６は、受け取った資源利用要求を資源選択部１１７に出力する。この際に、利用要求受付部１１６は、利用者の認証や利用者に対する課金などを行ってもよい。

資源選択部１１７は、利用要求受付部１１６から要求を入力し、資源状態管理ＤＢ１２４の情報を参照して、要求に対応する資源を選択する。資源選択部１１７は、資源状態管理ＤＢ１２４に保存されている情報を用いて、利用者が要求したサービス、資源量および資源の属性を満たす資源のうち、設定時間が短かい資源を選択する。要求を満たす資源が選択できた場合には、遷移指示部１１５に対して状態遷移依頼を行なう。要求を満たす資源が選択できなかった場合には、利用者に対して選択ができなかったことを伝える。

また、記憶装置１２０は、図３に示された第１の実施の形態における構成に加えて、資源状態管理ＤＢ１２４を備えている。資源状態管理ＤＢ１２４は、各資源が短時間で状態遷移可能なサービスの対応付け、または各サービスを利用可能な状態に遷移する時間すなわち設定時間が短かい資源の対応付けを保持する。この情報を資源選択部１１７が利用することにより、資源選択部１１７が実行する資源選択処理が短時間で済むことが期待される。

次に、図９および図１０のフローチャートを参照して本実施の形態の全体の動作について説明する。
図９には、図４に示された状態決定動作に、本実施の形態で必要になった処理が追加された処理の流れが示されている。ステップＡ１〜Ａ７までの処理は、第１の実施の形態における処理と同じである。本実施の形態では、ステップＡ７の状態決定部１１２が遷移指示部１１５に状態遷移を依頼する処理（資源状態遷移実行処理）の後に、資源状態保存処理が追加されている（ステップＡ８）。資源状態保存処理では、状態決定部１１２が、サービスとサービスを利用可能な状態に遷移する時間が短かい資源との対応付けを、資源状態管理ＤＢ１２４に保存する。

次に、図１０を参照して、資源利用要求受付処理の説明を行なう。
まず、利用要求受付部１１６は、サービス利用者から資源利用要求を受け取る（ステップＥ１）。資源利用要求には、サービス利用者が利用したいサービス、資源量および資源の属性などの情報が含まれている。それらの情報は資源選択に利用される。資源量は、計算機の台数、メモリ、ＣＰＵ使用率などであったり、ネットワークのバンド幅などである。資源の属性とは、計算機リソースのアーキテクチャ、ネットワーク構成などの物理的な属性や、資源の利用状況、利用サービス、利用者などの論理的な属性である。また、利用要求受付部１１６は、資源利用者の認証や課金情報のやりとりなどを行なうことも想定される。資源利用者の認証を行なう場合には、特定の利用者のみへのサービス提供が実現される。また、課金情報のやりとりを行なう場合には、利用者への適切な課金が実現される。

次に、資源利用要求を受け取った資源選択部１１７は、状態決定部１１２からサービスと資源との対応付けの情報を取得する（ステップＥ２）。この情報は、図９に示されたステップＡ８で状態決定部１１２が生成した情報である。

次いで、資源選択部１１７は、ステップＥ２で取得した資源、サービスと資源との対応付けの情報に従って、要求に合った資源を選択する（ステップＥ３）。このとき、資源選択部１１７は、必要に応じて状態取得部１１４から資源状態を取得したり、遷移時間予測部１１３から資源状態遷移にかかる予測時間を取得する。これらの情報にもとづいて、最適な資源を要求された量だけ選択する。

次に、資源選択に成功したか否かで、２つの動作に分かれる（ステップＥ４）。資源選択に成功した場合には、資源選択部１１７は、遷移指示部１１５に資源状態遷移実行要求を出力する。遷移指示部１１５は、資源の状態を変更する指示を、該当する計算機におけるエージェント２０１に対して行ない、資源状態遷移を実行させる（ステップＥ５）。その後、資源状態遷移の実行結果を、エージェント２０１から受け取り、要求元の利用者に通知する（ステップＥ６）。

資源選択に失敗した場合には、資源選択に失敗した旨を資源利用要求の要求元である利用者に通知する（ステップＥ７）。資源選択に失敗する状況は、要求量に応じるだけの待機資源がない場合であったり、資源の属性や資源設定時間などの要求を満たすことができない場合であったりする。この際、資源選択に失敗した理由も添えて通知してもよい。利用者は、資源選択に失敗した理由を判断することによって、今後の資源利用要求の要求内容を変更し、資源利用要求が受け入れられやすいようにすることが可能となる。

次に、本実施の形態の効果について説明する。本実施の形態では、利用者からの利用要求受付部１１６と資源選択部１１７が含まれているので、利用者からの利用要求に応えることができる。また、本実施の形態では、さらに、状態決定部１１２が、各サービスの設定時間が短かい資源をあらかじめ保存しておく処理を実行することによって、資源選択時間を短縮できる。つまり、状態決定部１１２は、利用する計算機リソースの選択を事前（実際に資源利用要求を受ける時点よりも前）に行なう資源選択手段を実現する。

実施の形態３．
次に、本発明の第３の実施の形態について図面を参照して説明する。
本実施の形態では、状態遷移規則の入力を簡易化することを目的とする。一つのまとまった状態遷移規則を人手で生成することは煩雑である。そのため、個々のサービスを設定する手順、またはサービスを設定するための状態遷移を入力とし、その入力から一つのまとまった状態遷移規則を生成することによって、状態遷移規則の入力の簡易化を実現する。

図１１は、本発明の第３の実施の形態における管理サーバ１００の構成を示すブロック図である。第３の実施の形態でも、管理サーバ１００は、データ処理装置１１０と記憶装置１２０とを含む。ただし、本実施の形態におけるデータ処理装置１１０は、図３に示された第１の実施の形態における構成に加えて、遷移手順入力部１１８および状態遷移合成部１１９を備えている。状態遷移合成部１１９は、複数の状態遷移規則を受け取り、それらを一つの状態遷移規則に合成する状態遷移規則手段の一例である。

遷移手順入力部１１８は、計算機リソースを特定のサービスを利用可能な状態に設定（状態遷移）させるための手順（状態遷移手順）を入力し、状態遷移合成部１１９に渡す。このとき、遷移手順入力部１１８は、入力者の認証や手順の確認を行ってもよい。状態遷移合成部１１９は、受け取った状態遷移手順を、一つの状態遷移図に合成する。具体的には、同じ状態を判断して一つの状態にまとめたり、共存可能な状態を判断して新しく状態として定義したりすることによって、複数の状態遷移手順を、一つの状態遷移図に合成する。このとき、できるだけ状態数を減らすことによって、最適な状態を決定する際にかかる時間を短縮することも可能になる。合成された状態遷移図は、状態遷移規則として、状態遷移規則ＤＢ１２１に保存される。

本実施の形態の動作を、図１２のフローチャートを参照して詳細に説明する。図１２には、状態遷移させるための手順（遷移手順）を入力してから、状態遷移図を生成し、保存するまでの動作が示されている。

まず、遷移手順入力部１１８は、複数の遷移手順を受け取る（ステップＧ１）。このとき、遷移手順入力部１１８は、入力者の認証や手順の確認を行ってもよい。遷移手順入力部１１８は、入力した遷移手順を状態遷移合成部１１９に渡す。

次に、状態遷移合成部１１９は、遷移手順の中の状態を比較して同一の状態を探し、同一の状態があれば、それらの手順をまとめる処理を行う。その処理を繰り返すことによって、複数の遷移手順は、一つの状態遷移図に合成される（ステップＧ２）。最後に、状態遷移合成部１１９は、合成された状態遷移図を、状態遷移規則として状態遷移規則ＤＢ１２１に保存する。

次に、本実施の形態の効果について説明する。本実施の形態では、複数の遷移手順を一つの状態遷移規則に合成することによって、状態遷移規則を用いた最適状態の決定を可能にする。また、複数の状態を比較してできるだけ状態数を減らすことによって、最適な状態を決定する際にかかる時間を短縮することができる。

次に、具体的な実施例を用いて本発明の実施の形態の動作を説明する。

実施例１．
第１の実施例は本発明の第１の実施の形態に対応する。本実施例では、計算機システムは、１台の管理サーバと、ネットワークとしてイーサネット（登録商標）ＬＡＮ（Local Area Network）で管理サーバに接続される複数台の計算機とで構成される。以下、管理サーバの構成として、図３に示された構成の管理サーバを例にする。

開始部１１１から処理開始要求を受けた状態決定部１１２は、状態遷移規則ＤＢ１２１から状態遷移規則を取得する。

図１３は、状態遷移規則を状態遷移図で表現した説明図である。図１３に示す状態遷移図では、状態０から状態９、状態Ａおよび状態Ｂが存在し、それぞれが向きのある枝で結ばれている。状態０から状態９は、サービスが稼働していない状態であり、状態ＡはサービスＡを提供可能な状態（サービスの利用が可能になる状態）、状態ＢはサービスＢを提供可能な状態である。各状態は、枝で結ばれた先の状態に対して遷移が可能である。例えば、状態１から状態２に遷移することは可能であるが、状態２から状態６に対して遷移することはできない。状態０から遷移が開始され、それぞれ中間状態を経てサービスを提供可能な状態である状態Ａ、または状態Ｂに遷移する。

次に、状態決定部１１２は、時間予測部１１３から状態遷移予測時間を取得する。時間予測部１１３は、状態遷移履歴ＤＢ１２３から遷移時間の履歴を取得する。遷移時間の履歴は、図１４の説明図に示された形で保持されている。図１４に示す例では、各状態から遷移した履歴が、順序立てて保持されている。例えば、状態０から状態１の遷移に要した時間は、最新のものは３秒（３ｓ）であり、その一つ前のものは４秒であることが例示されている。

状態遷移履歴を取得した時間予測部１１３は、状態遷移履歴から状態遷移時間を予測する。例えば、最新の遷移３つの平均を状態遷移時間の予測値とする。その場合、図１４に示された状態１から状態３の遷移の予測値は３分（３ｍ）になる。時間予測部１１３は、各状態遷移について状態遷移時間の予測値を状態決定部１１２に渡してもよいし、図１５の説明図に示すように、状態遷移図の各枝に予測値を付加した形で渡してもよい。図１５には、例えば、状態２から状態５まで遷移する予測時間が１４分であることが示されている。

遷移時間の予測値を取得した状態決定部１１２は、状態決定指標ＤＢ１２２から状態決定指標を取得する。図１６には、状態決定指標が要求の到着確率である場合のそれぞれの要求に対する到着確率が例示されている。例えば、サービスＡに一台の資源を割り当てる要求の到着確率は０．３であることが示されている。この指標は、状態決定部１１２が最適な状態を決定するために用いられる。

次に、状態決定指標を取得した状態決定部１１２は、現在の資源の状態を状態取得部１１４から取得する。状態取得部１１４は、各資源がどの状態にあるのかを判断し、判断結果を状態決定部１１２に渡す。図１７には、各資源の状態を状態遷移図にマッピングしたものが例示されている。図１７には、例えば、資源０および資源１は状態０にあることが示され、資源２は状態４にあることが示されている。

これらの情報を得た状態決定部１１２は、状態決定処理を行なう。図１８および図１９は、状態決定処理において全探索によって最適な状態を求める方法を示すフローチャートである。図１８は全探索を行なう動作を示し、図１９は、全探索の中で追加時間の期待値を計算する動作を示す。追加時間とは、計算機リソースが置かれている状態からサービスの利用が可能になる設定が完了するまでの時間である。従って、追加時間の期待値とは、例えば状態決定指標が要求の到着確率である場合には、それぞれの要求についての要求の到着確率と追加時間の予測値との積を加算した値である。

図１８に示すように、全探索を行なう場合には、状態決定部１１２は、まず、各計算機リソースの取り得る状態の組み合わせを全て列挙する（ステップＨ１）。次に、状態の組み合わせの中から一つの組み合せを選択する（ステップＨ２）。そして、選択された組み合せにおける状態に対して、追加時間の期待値を計算する（ステップＨ３）。選択されていない状態の組み合わせがないかを確認し（ステップＨ４）、全ての組み合わせに対してステップＨ３を実施し、追加時間の期待値を計算する。全ての組み合わせに対して期待値を計算したら、追加時間の期待値が最も小さい組み合わせを最適な状態として選択し（ステップＨ５）、終了する。

図１９は、図１８に示すステップＨ３の追加時間の期待値を計算する手順を示すフローチャートである。図１９に示すように、状態決定部１１２は、追加時間の期待値を計算するときに、まず、利用され得るサービスを一つ選択する（ステップＩ１）。次に、計算機リソース（資源）を一つ選択し（ステップＩ２）、選択された計算機リソースの状態から、選択されたサービスに状態遷移するための最小コストを求める（ステップＩ３）。これは、計算機リソースの状態からサービスを利用可能な状態への最短経路問題を解くことで求められる。最短経路問題については広く知られているため、ここでの説明は省略する。ステップＩ３の処理を全ての計算機リソースに対して行ない、全ての計算機リソースの状態からサービスを利用可能な状態に遷移するための、それぞれの最小コストを算出する。

次に、サービス要求に対する最適な計算機リソースをｎ個選択する（ステップＩ５）。個々の計算機リソース数に応じてサービス到着確率Ｐを掛け、状態遷移時間の予測期待値を得る（ステップＩ６）。ステップＩ２〜ステップＩ６の操作を全てのサービスおよび要求に対して行ない、予測期待値を足し合わせることによって、選択された組み合わせの期待値を得ることができる（ステップＩ８）。

上記のように最適な状態が求められたら、遷移指示部１１５によって各資源が最適な状態に遷移される。例えば、資源０が現在状態０にあり、最適な状態が状態５であると求められた場合には、資源０の状態は状態５まで遷移させられる。これらの状態遷移は、ＯＳのインストール作業であったり、ソフトウェアのインストールやソフトウェアの設定作業であったりする。全ての資源について最適な状態への遷移が終了した時点で、全体の処理が終了する。

全探索では計算量が大きく、最適な値を求めるために時間がかかることが予想される。そのような場合には、広く知られている最適化手法、例えば、山登り法などの近似解法を用いることで、短かい時間で最適に近い状態を求めることができる。

実施例２．
次に、第２の実施例を図面を参照して説明する。第２の実施例は、第２の実施の形態に対応する。本実施例でも、計算機システムは、１台の管理サーバと、ネットワークとしてイーサネットＬＡＮで管理サーバに接続される複数台の計算機とで構成される。以下、管理サーバの構成として、図８に示された構成の管理サーバを例にする。

最適な状態を求める動作において、第１の実施の形態と第２の実施の形態とで異なるのは、第２の実施の形態では、各サービスが利用可能な状態に遷移する時間が短かい資源の対応付けを保存する処理（ステップＡ８の処理）を実行することであった。第１の実施例における図１９に示すステップＩ３では、各計算機リソースからサービスに状態遷移を行なう最小予測時間が求められている。本実施例では、状態決定部１１２は、求められた最小予測時間を利用して、資源状態管理ＤＢ１２４に保存する項目を決定する。例えば、状態決定部１１２は、各サービスに対して、各計算機リソースと計算機リソースについての最小予測時間との対の情報を、最小予測時間が短い順に、資源状態管理ＤＢ１２４に保存する。

図２０は、資源状態管理ＤＢ１２４に保存されているテーブルの例を示す。図２０に示す例では、各サービスに対応して、計算機リソースと予測設定時間（設定時間の予測値）の対が予測設定時間をキーにソートされた状態で保持されている。図２０において、例えば、計算機リソースＲ０を、現在の状態からサービスＳ０を提供可能な状態に遷移させるまでに要する時間の予測値が３秒（３ｓ）であることが示されている。また、計算機リソースＲ３を、現在の状態からサービスＳ０を提供可能な状態に遷移させるまでに要する時間の予測値が７秒（７ｓ）であることが示されている。また、計算機リソースＲ５を、現在の状態からサービスＳ０を提供可能な状態に遷移させるまでに要する時間の予測値が１０時間（１０ｈ）であることが示されている。

次に、資源利用要求受付処理を、図２０に示された例を用いて説明する。資源利用要求として、サービスＳ１に資源が２個要求されたとする。このとき、資源選択部１１７は資源状態管理ＤＢ１２４に保持されているテーブルを見て選択処理を行なう。図２０に示されたテーブルでは、サービスＳ１を追加するにはＲ７で特定される計算機リソースとＲ３で特定される計算機リソースの設定時間が短かいことが示されているので、資源選択部はＲ７で特定される計算機リソースとＲ３で特定される計算機リソースとを選択する。

選択されたＲ７で特定される計算機リソースとＲ３で特定される計算機リソースとは、遷移指示部１１５によってサービスＳ１の状態まで遷移される。そして、遷移が成功した場合には、サービス利用者に対して遷移に成功したことが伝えられ、処理が終了する。

実施例３．
次に、第３の実施例を図面を参照して説明する。第３の実施例は、第３の実施の形態に対応する。本実施例でも、計算機システムは、１台の管理サーバと、ネットワークとしてイーサネットＬＡＮで管理サーバに接続される複数台の計算機とで構成される。以下、管理サーバの構成として、図１１に示された構成の管理サーバを例にする。

まず、状態遷移手順を受け取ってから、状態遷移図を生成し、保存するまでの動作を説明する。遷移手順入力部１１８は、複数の状態遷移手順を受け取る。状態遷移手順は、図２１（Ａ）に示されたようなものである。例えば、状態遷移手順Ａは、サービスＡを利用できる状態（状態Ａ）にするために、状態０から状態１、状態２などの遷移を繰り返す必要があることを示している。また、状態遷移手順Ｂ２は、状態１から状態３を経由しても、状態４を経由しても、どちらでも状態Ｂまで辿り着けることを示している。

状態遷移合成部１１９は、これらの状態遷移手順Ａ，Ｂ１，Ｂ２を合成する操作を行なう。図２１（Ａ）に示す状態遷移手順Ａおよび状態遷移手順Ｂ１を見ると、状態０から状態５までの遷移が同じものであることが判断できる。このような同じ状態を判断することによって、図２１（Ｂ）に示すような状態遷移図を得ることができる。ここで得られた状態遷移図を、状態遷移規則として状態遷移規則ＤＢ１２１に保存する。

また、図２２には、二つの異なる始状態（状態０および状態１０）を持ち、各状態間で始状態に向かって戻ることが可能であるような状態遷移図が示されている。このような状態遷移図においても、最適な状態を求めることが可能である。

実施例４．
次に、第４の実施例を説明する。
ここでは、計算機リソースの利用者としてのデータセンタがユーティリティコンピューティングによって計算機リソースを例えば時間単位で借り、計算機リソースを利用したウェブに関するサービスを一般ユーザに提供する場合を考える。以下、計算機リソースの利用者としてのデータセンタを、サービスプロバイダという。サービスプロバイダとして、ポータルサイトの提供者や、日本電気（ＮＥＣ）などのオンラインショッピングサービスが考えられる。

サービスプロバイダの管理者等は、例えば、ウェブページなどに対するアクセス数が増加すると予想される場合に、端末装置等を介して管理サーバ１００に計算機リソースの利用要求を出す。管理サーバ１００は、上記の各実施例のように動作し、計算機リソースを、サービスプロバイダに対してサービス提供可能な状態にする。この例では、サービスプロバイダが必要とする計算機リソースを、サービスプロバイダが利用可能な状態にする。

通常、サービスプロバイダは、一般ユーザに対してサービスを提供するのに必要な最低限の計算機リソースしか借り受けない。そして、アクセス数が増加すると予想される場合には、短時間で計算機リソースを増加させることが好ましい。さもないと、ウェブページなどへのアクセス要求に対する応答速度が低下し、サービスプロバイダによる一般ユーザに対するサービスの品質が低下してしまう。

以上に説明したように、上記の各実施の形態および各実施例によれば、計算機リソースは最適な中間状態に維持されているので、サービスプロバイダから要求があった場合に、短時間で、サービスプロバイダが必要とする計算機リソースをサービスプロバイダが利用可能な状態になる。その結果、サービスプロバイダによる一般ユーザに対するサービスの品質が低下することを防止できる。

本発明を、計算機リソースの状態を決め、設定する状態変更装置や、状態変更装置を複数の計算機リソースに実現するためのプログラムといった用途に適用できる。

第１の実施の形態の計算機システムを示すブロック図である。 サービスを提供するための計算機の構成を示すブロック図である。 管理サーバの構成を示すブロック図である。 第１の実施の形態における状態決定動作の流れを示すフローチャートである。 第１の実施の形態における時間予測部による遷移時間予測動作の流れを示すフローチャートである。 第１の実施の形態における状態取得部による資源状態取得動作の流れを示すフローチャートである。 第１の実施の形態における遷移指示部による状態遷移実行動作の流れを示すフローチャートである。 第２の実施の形態における管理サーバの構成を示すブロック図である。 第２の実施の形態における状態決定動作の流れを示すフローチャートである。 第２の実施の形態における資源利用要求受付処理を示すフローチャートである。 第３の実施の形態における管理サーバの構成を示すブロック図である。 遷移手順を入力してから状態遷移図を生成して保存するまでの動作の流れを示すフローチャートである。 第１の実施例における状態遷移規則を状態遷移図で表現した説明図である。 第１の実施例における遷移時間履歴ＤＢの内容を示す説明図である。 第１の実施例における状態遷移予測時間が付加された状態遷移図を示す説明図である。 第１の実施例における状態決定指標が要求の到着確率である場合のそれぞれの要求に対する到着確率を示す説明図である。 第１の実施例における資源状態と状態遷移予測時間が付加された状態遷移図を示す説明図である。 第１の実施例における資源の状態決定処理を全探索によって行なう動作を示すフローチャートである。 第１の実施例における資源の追加時間の期待値を求める動作を示すフローチャートである。 第２の実施例における資源状態管理ＤＢに保存されているテーブルの例を示す説明図である。 第３の実施例における状態遷移手順から合成される状態遷移図を示す説明図である。 第３の実施例における複数の開始状態を持ち各状態を戻ることが考慮されている状態遷移図を示す説明図である。

符号の説明

１００ 管理サーバ
１０１ ネットワーク
１０２，１０３，１０４ 計算機
１１０ データ処理装置
１１１ 開始部
１１２ 状態決定部
１１３ 時間予測部
１１４ 状態取得部
１１５ 遷移指示部
１１６ 利用要求受付部
１１７ 資源選択部
１１８ 遷移手順入力部
１１９ 遷移状態合成部
１２０ 記憶装置
１２１ 状態遷移規則ＤＢ
１２２ 状態決定指標ＤＢ
１２３ 遷移時間履歴ＤＢ
１２４ 資源状態管理ＤＢ

Claims (13)

1. 一つ以上の状態から状態遷移してサービスを提供可能なサービス提供可能状態になる複数の計算機リソースを有する計算機システムにおいて、
   前記各状態からサービス提供可能状態までの状態遷移を表す状態遷移規則を記憶する状態遷移規則記憶手段と、
   前記状態遷移規則で表される状態遷移に要する各時間を状態遷移履歴から予測して予測時間として出力する状態遷移時間予測手段と、
   前記状態遷移時間予測手段が予測した予測時間にもとづいて算出する時間であって複数の計算機リソースのそれぞれがとりうる状態の組み合わせにおける各状態からサービス提供可能状態になるまでに要する時間と所定の指標値との積の和が小さくなる組み合わせを決定する状態決定手段と、
   それぞれの計算機リソースを、前記状態決定手段が決定した組み合わせにおける状態に設定する状態遷移手段と
   を備えたことを特徴とする計算機システム。
2. 所定の指標値は、サービス要求の到着確率である請求項１記載の計算機システム。
3. 複数の状態遷移規則を一つの状態遷移規則に合成する状態遷移規則手段を備えた
   請求項１または請求項２記載の計算機システム。
4. 計算機リソースの状態を決定する際の指標を記憶する状態決定指標記憶手段を備え、
   状態決定手段は、前記状態決定指標記憶手段に記憶されている指標を用いて、計算機リソースの状態を決定する
   請求項１から請求項３のうちのいずれか１項に記載の計算機システム。
5. 一つ以上の状態から状態遷移してサービスを提供可能なサービス提供可能状態になる複数の計算機リソースを有する計算機システムにおけるそれぞれの計算機を管理する管理サーバであって、
   前記各状態からサービス提供可能状態までの状態遷移を表す状態遷移規則を記憶する状態遷移規則記憶手段と、
   前記状態遷移規則で表される状態遷移に要する各時間を状態遷移履歴から予測して予測時間として出力する状態遷移時間予測手段と、
   前記状態遷移時間予測手段が予測した予測時間にもとづいて算出する時間であって複数の計算機リソースのそれぞれがとりうる状態の組み合わせにおける各状態からサービス提供可能状態になるまでに要する時間と所定の指標値との積の和が小さくなる組み合わせを決定する状態決定手段と、
   それぞれの計算機リソースを、前記状態決定手段が決定した組み合わせにおける状態に設定する状態遷移手段と
   を備えたことを特徴とする管理サーバ。
6. 一つ以上の状態から状態遷移してサービスを提供可能なサービス提供可能状態になる複数の計算機リソースを有する計算機システムにおける計算機設定時間を低減する方法であって、
   状態遷移規則記憶手段に記憶されている前記各状態からサービス提供可能状態までの状態遷移を表す状態遷移規則で表される状態遷移に要する各時間を状態遷移履歴から予測して予測時間として出力する状態遷移時間予測処理を行い、
   前記状態遷移時間予測処理で出力される予測時間にもとづいて算出する時間であって複数の計算機リソースのそれぞれがとりうる状態の組み合わせにおける各状態からサービス提供可能状態になるまでに要する時間と所定の指標値との積の和が小さくなる組み合わせを決定する状態決定処理を行い、
   それぞれの計算機リソースを、前記状態決定処理で決定された組み合わせにおける状態に設定する
   ことを特徴とする計算機設定時間を低減する方法。
7. 所定の指標値は、サービス要求の到着確率である
   請求項６記載の計算機設定時間を低減する方法。
8. 複数の状態遷移規則を一つの状態遷移規則に合成する
   請求項６または請求項７記載の計算機リソース設定時間を低減する方法。
9. 計算機リソースの状態を決定するときに、状態決定指標記憶手段に記憶されている計算機リソースの状態を決定する際の指標を用いる
   請求項６から請求項８のうちのいずれか１項に記載の計算機設定時間を低減する方法。
10. 一つ以上の状態から状態遷移してサービスを提供可能なサービス提供可能状態になる複数の計算機リソースを有する計算機システムにおけるそれぞれの計算機を管理するコンピュータに、
    状態遷移規則記憶手段に記憶されている前記各状態からサービス提供可能状態までの状態遷移を表す状態遷移規則で表される状態遷移に要する各時間を状態遷移履歴から予測して予測時間として出力する状態遷移時間予測処理と、
    前記状態遷移時間予測処理で出力される予測時間にもとづいて算出する時間であって複数の計算機リソースのそれぞれがとりうる状態の組み合わせにおける各状態からサービス提供可能状態になるまでに要する時間と所定の指標値との積の和が小さくなる組み合わせを決定する状態決定処理と、
    それぞれの計算機リソースを、前記状態決定処理で決定された組み合わせにおける状態に設定する処理と
    を実行させるための計算機設定時間を低減するためのプログラム。
11. 所定の指標値は、サービス要求の到着確率である
    請求項１０記載の計算機設定時間を低減するためのプログラム。
12. コンピュータに、
    複数の状態遷移規則を一つの状態遷移規則に合成する状態遷移規則処理を実行させるための
    請求項１０または請求項１１記載の計算機リソース設定時間を低減するためのプログラム。
13. コンピュータに、
    計算機リソースの状態を決定する際の指標を記憶させる処理を実行させ、
    前記状態決定指標記憶手段に記憶されている指標を用いて状態決定処理を実行させるための
    請求項１０から請求項１２のうちのいずれか１項に記載の計算機リソース設定時間を低減するためのプログラム。

Images