JP2019046163A - 情報処理装置、仮想マシン監視プログラム、および情報処理システム - Google Patents

情報処理装置、仮想マシン監視プログラム、および情報処理システム Download PDF

Info

Publication number
JP2019046163A
JP2019046163A JP2017168719A JP2017168719A JP2019046163A JP 2019046163 A JP2019046163 A JP 2019046163A JP 2017168719 A JP2017168719 A JP 2017168719A JP 2017168719 A JP2017168719 A JP 2017168719A JP 2019046163 A JP2019046163 A JP 2019046163A
Authority
JP
Japan
Prior art keywords
virtual machine
amount
resource
request
change
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2017168719A
Other languages
English (en)
Other versions
JP6940761B2 (ja
Inventor
勝 新満
Masaru Aramitsu
勝 新満
杉雄 渡辺
Sugio Watanabe
杉雄 渡辺
木村 修
Osamu Kimura
修 木村
暢 小林
Noboru Kobayashi
暢 小林
裕一 阪上
Yuichi Sakagami
裕一 阪上
亮祐 鈴木
Ryosuke Suzuki
亮祐 鈴木
豪 梅月
Takeshi Umezuki
豪 梅月
直也 岩下
Naoya Iwashita
直也 岩下
村上 浩
Hiroshi Murakami
浩 村上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2017168719A priority Critical patent/JP6940761B2/ja
Publication of JP2019046163A publication Critical patent/JP2019046163A/ja
Application granted granted Critical
Publication of JP6940761B2 publication Critical patent/JP6940761B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Debugging And Monitoring (AREA)

Abstract

【課題】仮想マシンに割り当てるリソース量の最適化の遅延を抑止する。【解決手段】情報処理装置10は、サーバ3が実行している仮想マシン3cに送信された単位期間当たりのリクエストの量を監視する。次に情報処理装置10は、リクエストの量の時系列での変化度合いに基づいて、仮想マシン3cの実行に使用可能なハードウェアリソースの量を変更するか否かを決定する。変更すると決定した場合、情報処理装置10は、仮想マシン3cの実行に使用可能なハードウェアリソースの量の変更を、サーバ3に指示する。【選択図】図1

Description

本発明は、情報処理装置、仮想マシン監視プログラム、および情報処理システムに関する。
クラウドコンピューティングシステムでは、例えば、サーバ上に構築された仮想マシンを用いてサービスが提供される。クラウドコンピューティングシステムにおいて新たなサービスの提供を開始する場合、そのサービスの負荷に応じた性能の仮想マシンが、サーバ上に構築される。仮想マシンの性能は、その仮想マシンの実行のために使用可能なハードウェアリソース(以下、単にリソースと呼んだ場合もハードウェアリソースを指す)の量に依存する。仮想マシンの実行のために使用可能なリソースを設定することを、仮想マシンにリソースを割り当てると呼ぶこともある。仮想マシンに割り当てられるリソースは、CPU(Central Processing Unit)、メモリ、ストレージ装置などである。これらのリソースの量が多いほど、仮想マシンの性能が高くなる。
ここで、仮想マシンに割り当てるリソースの量が少なすぎると、仮想マシンを用いて提供されるサービスに求められる品質でのサービス提供ができない。他方、仮想マシンに割り当てるリソースの量が多すぎると、システム内のリソースが無駄に消費されてしまう。
そこで、例えばクラウド・システムにおいて、性能の低下を抑制して、適切な計算機リソースを提供するための計算器リソース割り当て方法が考えられている。この計算器リソース割り当て方法では、管理計算機が、サービスを提供する仮想計算機群の性能を取得して、取得した仮想計算機群の性能と、予め設定されたサービスの性能条件とを比較する。そして管理計算機は、比較結果に応じて、仮想計算機群で変更する計算機リソースを決定する。
特開2016−103179号公報
しかし、仮想マシンの性能が悪化したことを確認してから仮想マシンのリソース量を変更したのでは、仮想マシンの性能が悪化してから、割り当てるリソース量が変更されるまでに遅延が生じる。その結果、リソース量の変更処理が完了するまでの一定期間、サービスの品質が低下してしまう。
1つの側面では、本件は、仮想マシンに割り当てるリソース量の最適化の遅延を抑止することを目的とする。
1つの案では、以下の処理部を有する情報処理装置が提供される。
処理部は、サーバが実行している仮想マシンに送信された単位期間当たりのリクエストの量を監視する。次に処理部は、リクエストの量の時系列での変化度合いに基づいて、仮想マシンの実行に使用可能なハードウェアリソースの量を変更するか否かを決定する。変更すると決定した場合、処理部は、仮想マシンの実行に使用可能なハードウェアリソースの量の変更を、サーバに指示する。
1態様によれば、仮想マシンに割り当てるリソース量の最適化の遅延を抑止する。
第1の実施の形態に係る仮想マシン監視システムの構成の一例を示す図である。 第2の実施の形態のシステム構成例を示す図である。 第2の実施の形態に用いる仮想マシン監視装置のハードウェアの一構成例を示す図である。 仮想マシンへ割り当て資源量を変更するために各装置が有する機能を示すブロック図である。 リクエスト監視テーブルの一例を示す図である。 リソース管理テーブルの一例を示す図である。 仮想マシン管理テーブルの一例を示す図である。 リソース優先度テーブルの一例を示す図である。 ロードバランサが記憶するリクエスト管理テーブルの一例を示す図である。 リクエスト監視処理の手順の一例を示すシーケンス図である。 最適化処理の手順の一例を示すシーケンス図である。 仮想マシン監視装置におけるリクエスト監視処理の手順の一例を示すフローチャートの前半である。 仮想マシン監視装置におけるリクエスト監視処理の手順の一例を示すフローチャートの後半である。 リクエスト量・レスポンスタイム計測処理の手順の一例を示すフローチャートである。 コスト改善処理の手順の一例を示すフローチャートの前半である。 コスト改善処理の手順の一例を示すフローチャートの後半である。 レスポンス改善処理の手順の一例を示すフローチャートの前半である。 レスポンス改善処理の手順の一例を示すフローチャートの後半である。
以下、本実施の形態について図面を参照して説明する。なお各実施の形態は、矛盾のない範囲で複数の実施の形態を組み合わせて実施することができる。
〔第1の実施の形態〕
まず、第1の実施の形態について説明する。
図1は、第1の実施の形態に係る仮想マシン監視システムの構成の一例を示す図である。複数の端末装置1a,1bが、ネットワーク2を介してサーバ3に接続されている。サーバ3は、ハードウェアリソースとしてCPU3a−1,3a−2,・・・、メモリ3b−1,3b−2,・・・などを有している。サーバ3は、ハードウェアリソースの少なくとも一部を用いて仮想マシン3cを実行する。サーバ3は、仮想マシン3cの実行に使用可能なハードウェアリソースの量を、自動で変更可能である。サーバ3により実現される仮想マシン3cは、端末装置1a,1bからのリクエストに応じて処理を実行し、処理結果をレスポンスとして端末装置1a,1bに送信する。
情報処理装置10は、サーバ3が実行している仮想マシン3cに対して送信されるリクエストを監視して、リクエスト量の変化が過大な場合に、仮想マシン3cの実行に使用可能なハードウェアリソースの量の変更を、サーバ3に指示する。そのために、情報処理装置10は、記憶部11と処理部12とを有する。記憶部11は、例えば情報処理装置10が有するメモリ、またはストレージ装置である。処理部12は、例えば情報処理装置10が有するプロセッサ、または演算回路である。
記憶部11は、単位期間当たりのリクエストの量を記憶する。例えば記憶部11は、直近の単位期間(第1の単位期間)内のリクエスト量と、直近の単位期間の直前(第2の単位期間)内のリクエスト量とを記憶する。
処理部12は、監視結果により得られた単位期間当たりのリクエスト量に基づいて、仮想マシン3cの実行に使用可能なリソースの量を変更させるか否かを決定し、変更させる場合には、変更の指示をサーバ3に送信する。そのために処理部12は、サーバ3が実行している仮想マシン3cに送信された単位期間当たりのリクエストの量を監視する。例えば処理部12は、ネットワーク2内で端末装置1a,1bからサーバ3に送信されるリクエストを中継する装置に、単位期間当たりのリクエスト量を計数させ、処理部12はその装置から単位期間当たりのリクエスト量を示す情報を取得する。リクエストを中継する装置は、例えばロードバランサである。また処理部12は、ネットワーク2を介して通信されるパケットをキャプチャし、キャプチャしたパケットを解析して、仮想マシン3cに送信されたリクエスト量を計測することもできる。処理部12は、単位期間当たりに仮想マシン3cに送信されたリクエスト量を、記憶部11に格納する。
処理部12は、仮想マシン3cに送信された単位期間当たりのリクエストの量の時系列での変化度合いに基づいて、仮想マシンの実行に使用可能なハードウェアリソースの量を変更するか否かを決定する。単位期間当たりのリクエストの量の時系列での変化度合いは、例えば変動率で表される。変動率は、第1の単位期間内のリクエスト量を第2の単位期間内のリクエスト量で除算した値である。
例えば、処理部12は、直近の第1の単位期間でのリクエストの量を、第1の単位期間の直前の第2の単位期間でのリクエストの量と比較したときの変化度合いが閾値を超えているか否かを判定する。変化の度合いが閾値を超えている場合、処理部12は、仮想マシン3cの実行に使用可能なハードウェアリソースの量を変更すると決定する。
なお、ハードウェアリソースの量を変更するか否かの判定に用いる閾値として、複数の閾値を用いることができる。第1の閾値は1未満の正の実数(例えば「0.5」)であり、第2の閾値は1より大きい実数(例えば「1.5」)である。処理部12は、第1の単位期間でのリクエストの量が、第2の単位期間でのリクエストの量よりも減少しており、減少の度合いが第1の閾値を超えている場合、仮想マシン3cの実行に使用可能なハードウェアリソースの量を減少させることを決定する。減少の度合いが第1の閾値を超えているとは、例えば変動率が第1の閾値未満になっていることである。また処理部12は、第1の単位期間でのリクエストの量が、第2の単位期間でのリクエストの量よりも増加しており、増加の度合いが第2の閾値を超えている場合、仮想マシン3cの実行に使用可能なハードウェアリソースの量を増加させることを決定する。増加の度合いが第2の閾値を超えているとは、例えば変動率が第2の閾値より大きいことである。
処理部12は、仮想マシン3cの実行に使用可能なハードウェアリソースの量を変更すると決定した場合、仮想マシン3cの実行に使用可能なハードウェアリソースの量の変更を、サーバ3に指示する。例えば処理部12は、ハードウェアリソースの量を減少させることを決定した場合、仮想マシン3cの実行に使用可能なハードウェアリソースの量を減少させることを、サーバ3に指示する。また処理部12は、ハードウェアリソースの量を増加させることを決定した場合、仮想マシン3cの実行に使用可能なハードウェアリソースの量を増加させることを、サーバ3に指示する。
このような仮想マシン監視システムによれば、仮想マシン3cに対する単位期間当たりのリクエストの量が、ある程度以上減少傾向または増加傾向にある場合、仮想マシン3cの実行に使用可能なハードウェアリソースを減少または増加させることができる。すなわちリクエストの量に基づいて、仮想マシン3cの実行に使用可能なハードウェアリソースの量を最適化することができる。これにより、仮想マシン3cの性能が悪化したことを確認してからハードウェアリソースの量を変更する場合に比べ、仮想マシン3cに割り当てるリソースの量の最適化の遅延が抑止される。
例えば、仮想マシンの性能は、リクエストに対するレスポンスタイム(リクストを送信してからレスポンスを受信するまでの時間)によって計測できる。仮想マシンなどの計算機の性質として、所定の負荷までは、十分に短いレスポンスタイムでサービスを提供できるが、負荷が所定量を超えると、急激にレスポンスタイムが悪化する場合がある。このような場合、レスポンスタイムの悪化を確認してから仮想マシンのリソース量を増加させたのでは、仮想マシンのリソース量を増加させる処理が完了するまで、レスポンスタイムが悪化したままとなり、サービスの品質の低下を招く。しかもレスポンスタイムが悪化した後に、レスポンスタイムの要件を満たす最適なハードウェアリソース構成を探索すると、探索に時間を要し、サービスの品質の低下期間が長期化する。なお、レスポンスタイムの要件は、例えばレスポンスタイムが所定の閾値未満であることである。
それに対し、図1に示す仮想マシン監視システムでは、単位期間当たりのリクエスト量の増加傾向が検知できた段階で、仮想マシン3cの実行に使用可能なハードウェアリソースが自動で追加される。すなわち、リクエスト量の増加傾向が継続しても、それに応じて仮想マシン3cの実行に使用可能なハードウェアリソースの量も増加し、レスポンスタイムが悪化することを抑止できる。
しかも図1に示す仮想マシン監視システムでは、単位期間当たりのリクエスト量が減少傾向に転じた場合、仮想マシン3cの実行に使用可能なハードウェアリソースの量は自動で削減される。その結果、仮想マシン3cの実行のために、無駄に多くのハードウェアリソースが使用されることが抑止される。その結果、サーバ3のハードウェアリソースの効率的な利用が可能となる。
なお、処理部12は、ハードウェアリソースの種別(CPU、メモリなど)ごとに、仮想マシン3cの実行に使用可能とする量の変更の優先度を決定しておいてもよい。例えば、処理部12は、サーバ3からハードウェアリソースの種別ごとの仮想マシン3cの使用率を取得し、使用率が高い種別のハードウェアリソースほど、優先度を高くする。この際、情報処理装置10では、ハードウェアリソースの種別ごとの、仮想マシン3cの実行に使用可能とする最大値と最小値とを定めておく。例えば情報処理装置10は、記憶部11に予めリソース管理情報を記憶しておく。リソース管理情報には、ハードウェアリソースの種別ごとに、仮想マシン3cの実行に使用可能とする量の変更の優先度、仮想マシン3cの実行に使用可能とする量の最小値、および仮想マシンの実行に使用可能とする量の最大値が示される。
処理部12は、仮想マシンの実行に使用可能なハードウェアリソースの量を増加させると決定した場合、リソース管理情報に基づいて、最大値を超えない範囲で、優先度が最も高い種別のハードウェアリソースを増加させることを決定する。優先度が最も高い種別のハードウェアリソースの量がすでに最大値になっている場合、処理部12は、次に優先度が高い種別のハードウェアリソースを、最大値を超えない範囲で増加させることを決定する。
また処理部12は、仮想マシンの実行に使用可能なハードウェアリソースの量を減少させると決定した場合、リソース管理情報に基づいて、最小値を下回らない範囲で、優先度が最も高い種別のハードウェアリソースを減少させることを決定する。優先度が最も高い種別のハードウェアリソースの量がすでに最小値になっている場合、処理部12は、次に優先度が高い種別のハードウェアリソースを、最小値を下回らない範囲で減少させることを決定する。
このように、ハードウェアリソースの種別ごとの使用率に基づいて、リソースの量を変更させる優先度を決定しておくことで、仮想マシン3cのレスポンスタイムの悪化原因となる可能性の高いハードウェアリソースを、優先的に増加させることができる。その結果、仮想マシン3cの実行に使用可能なハードウェアリソースの量の変更を効率的に行うことができる。
すなわち、ハードウェアリソースの種別ごとの使用率を用いずにハードウェアリソースの量の変更を行うと、仮想マシン3cのレスポンスタイムの悪化原因にはならない種別のハードウェアリソースを増強してしまう可能性がある。この場合、仮想マシン3cの実行に使用可能なハードウェアリソースを増強したにも関わらず、リクエストの量の増加に伴いレスポンスタイムの悪化を抑止することができない。それに対して、ハードウェアリソースの種別ごとの使用率に基づいてリソースの量を変更させる優先度を決定することで、レスポンスタイムの悪化原因となる可能性の高い種別のハードウェアリソースの量を優先的に増加させることができる。
なお、仮想マシン3cとは別に、仮想マシン3cの実行に使用可能とするハードウェアリソースと同じ量のハードウェアリソースを使用可能な検証用の仮想マシンを立ち上げ、検証用の仮想マシンで適切なハードウェアリソース量を探索することもできる。しかし、ハードウェアリソースの種別ごとの使用率を考慮せずに、検証用の仮想マシンを用いた探索を行うと、ハードウェアリソース構成の異なる多数の仮想マシンのなかから、要件を満足する仮想マシンを特定することとなる。例えば、仮想マシンのCPU使用率が高く、CPU不足がレスポンスタイムの悪化要因となる可能性がある場合でも、メモリリソースの量を拡張した検証用の仮想マシンについても探索の対象となる。その結果、最適なハードウェアリソース構成の特定に時間がかかる。それに対して、ハードウェアリソースの種別ごとの使用率に基づいて、ハードウェアリソースの量を変更させる優先度を決定することで、レスポンスタイムの悪化要因となる種別のハードウェアリソースを変更した場合について優先的に探索できる。これによりレスポンスタイムの要件を満たすハードウェアリソース構成を早期に特定できる。すなわち、仮想マシンの実行に使用可能とする最適なハードウェアリソース構成の探索を効率的に行うことができる。
〔第2の実施の形態〕
次に第2の実施の形態について説明する。第2の実施の形態は、運用中の仮想マシンに対するリクエスト量に応じて、その仮想マシンの実行に使用可能なハードウェアリソースの量を変更する。また第2の実施の形態では、運用中の仮想マシンの実行に使用可能なハードウェアリソースの量を変更する前に、検証用の仮想マシンを用いて、レスポンスタイムの要件が満たされるかどうかを検証する。
なお、以下の説明では、ハードウェアリソースを単にリソースと呼ぶ。また仮想マシンの実行に使用可能なリソースを設定することを、仮想マシンへのリソースの割り当てと呼ぶ。
図2は、第2の実施の形態のシステム構成例を示す図である。クラウドコンピューティングシステムには、仮想マシン監視装置100、ロードバランサ200、およびサーバ300が含まれる。仮想マシン監視装置100、ロードバランサ200、およびサーバ300は、管理ネットワーク20で接続されている。管理ネットワーク20は、クラウドコンピューティングシステムの運用管理用のネットワークである。またロードバランサ200とサーバ300とは、業務ネットワーク41で接続されている。業務ネットワーク41は、ロードバランサ200が端末装置31,32,・・・から受信したリクエストのサーバ300への転送、およびリクエストに対するサーバ300からのレスポンスの送信に使用するネットワークである。
仮想マシン監視装置100は、サーバ300内の仮想マシンに送信されたリクエストの量に基づいて、その仮想マシンに割り当てるリソース量を管理する。例えば仮想マシン監視装置100は、仮想マシンに送信された単位期間当たりのリクエスト量の増加率が、増加率の閾値を超えている場合、その仮想マシンへの資源の追加をサーバ300に指示する。また仮想マシン監視装置100は、仮想マシンに送信された単位期間当たりのリクエスト量の減少率が、減少率の閾値を超えている場合、その仮想マシンの資源の削減をサーバ300に指示する。
ロードバランサ200は、ネットワーク42を介して複数の端末装置31,32,・・・に接続されている。複数の端末装置31,32,・・・それぞれは、サービスを利用するユーザが使用するコンピュータである。ロードバランサ200は、複数の端末装置31,32,・・・のいずれかから送られたリクエストを、サーバ300内の複数の仮想マシンのいずれかに転送する。またロードバランサ200は、リクエストに対するレスポンスをサーバ300内の複数の仮想マシンのいずれかから受信すると、そのレスポンスを、対応するリクエストの送信元の端末装置に転送する。ロードバランサ200は、さらに、仮想マシン監視装置100からの依頼に基づいて、仮想マシンに転送した単位期間当たりのリクエストの量と、リクエストに対するレスポンスタイムを計測する。ロードバランサ200は、計測結果を、仮想マシン監視装置100に送信する。
サーバ300は、サービスを提供するコンピュータである。サーバ300は、内部で複数の仮想マシンを生成する。複数の仮想マシンそれぞれには、サーバ300が有するリソース(CPU、メモリ、ストレージ装置など)の少なくとも一部が割り当てられる。サーバ300内の複数の仮想マシンそれぞれが、割り当てられたリソースを用いて、端末装置31,32,・・・に対するサービスを提供する。
図3は、第2の実施の形態に用いる仮想マシン監視装置のハードウェアの一構成例を示す図である。仮想マシン監視装置100は、プロセッサ101によって装置全体が制御されている。プロセッサ101には、バス109を介してメモリ102と複数の周辺機器が接続されている。プロセッサ101は、マルチプロセッサであってもよい。プロセッサ101は、例えばCPU、MPU(Micro Processing Unit)、またはDSP(Digital Signal Processor)である。プロセッサ101がプログラムを実行することで実現する機能の少なくとも一部を、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)などの電子回路で実現してもよい。
メモリ102は、仮想マシン監視装置100の主記憶装置として使用される。メモリ102には、プロセッサ101に実行させるOS(Operating System)のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、メモリ102には、プロセッサ101による処理に利用する各種データが格納される。メモリ102としては、例えばRAM(Random Access Memory)などの揮発性の半導体記憶装置が使用される。
バス109に接続されている周辺機器としては、ストレージ装置103、グラフィック処理装置104、入力インタフェース105、光学ドライブ装置106、機器接続インタフェース107およびネットワークインタフェース108がある。
ストレージ装置103は、内蔵した記録媒体に対して、電気的または磁気的にデータの書き込みおよび読み出しを行う。ストレージ装置103は、コンピュータの補助記憶装置として使用される。ストレージ装置103には、OSのプログラム、アプリケーションプログラム、および各種データが格納される。なお、ストレージ装置103としては、例えばHDD(Hard Disk Drive)やSSD(Solid State Drive)を使用することができる。
グラフィック処理装置104には、モニタ21が接続されている。グラフィック処理装置104は、プロセッサ101からの命令に従って、画像をモニタ21の画面に表示させる。モニタ21としては、CRT(Cathode Ray Tube)を用いた表示装置や液晶表示装置などがある。
入力インタフェース105には、キーボード22とマウス23とが接続されている。入力インタフェース105は、キーボード22やマウス23から送られてくる信号をプロセッサ101に送信する。なお、マウス23は、ポインティングデバイスの一例であり、他のポインティングデバイスを使用することもできる。他のポインティングデバイスとしては、タッチパネル、タブレット、タッチパッド、トラックボールなどがある。
光学ドライブ装置106は、レーザ光などを利用して、光ディスク24に記録されたデータの読み取りを行う。光ディスク24は、光の反射によって読み取り可能なようにデータが記録された可搬型の記録媒体である。光ディスク24には、CD−ROM(Compact Disc Read Only Memory)、CD−R(Recordable)/RW(ReWritable)などがある。
機器接続インタフェース107は、仮想マシン監視装置100に周辺機器を接続するための通信インタフェースである。例えば機器接続インタフェース107には、メモリ装置25やメモリリーダライタ26を接続することができる。メモリ装置25は、機器接続インタフェース107との通信機能を搭載した記録媒体である。メモリリーダライタ26は、メモリカード27へのデータの書き込み、またはメモリカード27からのデータの読み出しを行う装置である。メモリカード27は、カード型の記録媒体である。
ネットワークインタフェース108は、管理ネットワーク20に接続されている。ネットワークインタフェース108は、管理ネットワーク20を介して、他のコンピュータまたは通信機器との間でデータの送受信を行う。
以上のようなハードウェア構成によって、第2の実施の形態の仮想マシン監視装置100の処理機能を実現することができる。なお仮想マシン監視装置100に対しては、機器接続インタフェース107、またはネットワークインタフェース108を介してデータの入出力を行うことができる。そのため仮想マシン監視装置100には、モニタ21、キーボード22、マウス23などの入出力装置を接続しなくてもよい。また仮想マシン監視装置100は、光学ドライブ装置106を有していなくてもよい。
ロードバランサ200とサーバ300も、図3に示した仮想マシン監視装置100と同様のハードウェアにより実現することができる。また、第1の実施の形態に示した情報処理装置10も、図3に示した仮想マシン監視装置100と同様のハードウェアにより実現することができる。
仮想マシン監視装置100は、例えばコンピュータ読み取り可能な記録媒体に記録されたプログラムを実行することにより、第2の実施の形態の処理機能を実現する。仮想マシン監視装置100に実行させる処理内容を記述したプログラムは、様々な記録媒体に記録しておくことができる。例えば、仮想マシン監視装置100に実行させるプログラムをストレージ装置103に格納しておくことができる。プロセッサ101は、ストレージ装置103内のプログラムの少なくとも一部をメモリ102にロードし、プログラムを実行する。また仮想マシン監視装置100に実行させるプログラムを、光ディスク24、メモリ装置25、メモリカード27などの可搬型記録媒体に記録しておくこともできる。可搬型記録媒体に格納されたプログラムは、例えばプロセッサ101からの制御により、ストレージ装置103にインストールされた後、実行可能となる。またプロセッサ101が、可搬型記録媒体から直接プログラムを読み出して実行することもできる。
以上のような構成のシステムにおいて、仮想マシン監視装置100、ロードバランサ200、およびサーバ300が連携して動作することで、運用中の仮想マシンに割り当てるリソース量を動的に変更することができる。なお、第2の実施の形態では、運用中の仮想マシンに割り当てるリソース量を変更する前に、運用中の仮想マシンのクローンを用いて、リソース量を変更してもよいかどうかが検証される。そして検証の結果問題がない場合に、運用中の仮想マシンに割り当てるリソース量が変更される。
以下の説明では、運用中の仮想マシンを、単に運用マシンと呼ぶこともある。また運用マシンのクローンとして生成される検証用の仮想マシンを、改善マシンと呼ぶこともある。
図4は、仮想マシンへ割り当て資源量を変更するために各装置が有する機能を示すブロック図である。仮想マシン監視装置100は、記憶部110と監視部120とを有する。
記憶部110は、リクエスト監視テーブル111、リソース管理テーブル112、仮想マシン管理テーブル113、およびリソース優先度テーブル114を記憶する。リクエスト監視テーブル111は、運用中の仮想マシンに送信されたリクエストの量と、リクエストに対するレスポンスタイムを管理するためのデータテーブルである。リソース管理テーブル112は、仮想マシンに割り当てるリソースを管理するためのデータテーブルである。仮想マシン管理テーブル113は、仮想マシンの使用目的、現在のリソース構成、レスポンスタイムなどを管理するためのデータテーブルである。記憶部110は、例えば仮想マシン監視装置100が有するメモリまたはストレージ装置の記憶領域の一部を用いて実現される。
監視部120は、仮想マシン331,332,・・・へのリクエストの量に基づいて、仮想マシン331,332,・・・へ割り当てるリソースの増減を決定する。そして監視部120は、決定に従って、サーバ300に対して、仮想マシン331,332,・・・のリソースの追加、または仮想マシン331,332,・・・からのリソースの削除を指示する。監視部120は、このような仮想マシン331,332,・・・のリソースの管理を、オペレータによって予め設定された情報に基づき自動で実行する。
ロードバランサ200は、記憶部210、負荷分散制御部220、および負荷計測部230を有する。
記憶部210は、ロードバランサ200において仮想マシン331,332,・・・に転送したリクエストに関する情報(リクエスト情報)を蓄積したリクエスト管理テーブル211を記憶する。記憶部210は、例えばロードバランサ200が有するメモリまたはストレージ装置の記憶領域の一部を用いて実現される。
負荷分散制御部220は、複数の端末装置31,32,・・・から受信したリクエストを、サーバ300内の仮想マシン331,332,・・・のうちの運用中の仮想マシンに転送する。例えば負荷分散制御部220は、運用中の仮想マシンが複数ある場合、それらの仮想マシンの負荷が均等になるように、リクエストの転送先を決定する。また負荷分散制御部220は、サーバ300内の運用中の仮想マシンからリクエストに対するレスポンスを受信すると、そのリクエストの送信元の端末装置へ、受信したレスポンスを送信する。
負荷計測部230は、運用中の仮想マシンへ転送したリクエスト量と、リクエストに対するレスポンスタイムとを計測する。例えば負荷計測部230は、監視部120からのリクエスト量とレスポンスタイムとの監視指示に応じて、監視指示で指定された仮想マシンのリクエスト量とレスポンスタイムとを計測する。
また負荷計測部230は、複数の仮想マシン331,332,・・・それぞれへ転送したリクエストに関する情報を、リクエスト情報として記憶部210内のリクエスト管理テーブル211に格納する。そして負荷計測部230は、仮想マシン監視装置100からの改善マシンとして生成された仮想マシンのレスポンスタイム特定指示に応じて、リクエスト情報に基づくリクエストを該当する仮想マシンに送信する。負荷計測部230は、改善マシンである仮想マシンからのリクエストに対するレスポンスタイムを計測する。負荷計測部230は、計測したレスポンスタイムを、仮想マシン監視装置100に送信する。
サーバ300は、記憶部310とハイパーバイザ320とを有している。
記憶部310は、複数の仮想マシン321,322,・・・のいずれかのスナップショット311を記憶する。スナップショットは、特定の時点における運用中の仮想マシンの状態を再現可能な情報である。例えばスナップショットには、運用中の仮想マシンのメモリ内の情報、ストレージ装置内容の情報、CPUのレジスタ内の情報が含まれる。
ハイパーバイザ320は、複数の仮想マシン331,332,・・・を管理する。具体的には、ハイパーバイザ320は、複数の仮想マシン331,332,・・・それぞれに割り当てるリソースを決定し、割り当てたリソースを用いて複数の仮想マシン331,332,・・・を稼働させる。例えばハイパーバイザ320は、仮想マシン331を生成する場合、サーバ300のリソースのなかから、仮想マシン331に割り当てるリソースの量を決定する。次にハイパーバイザ320は、決定した量のリソースにより、仮想CPU331a、仮想メモリ331b、および仮想ストレージ装置331cを生成する。ハイパーバイザ320は、これらの仮想的なリソースを有する仮想マシン331を生成する。仮想マシン331では、例えば業務アプリケーションソフトウェア331dを実行する。仮想マシン331は、業務アプリケーションソフトウェア331dを実行することで、例えばアプリケーションサーバとして機能する。そして仮想マシン331は、業務アプリケーションソフトウェア331dに基づいて、受信したリクエストに対する処理を実行し、処理結果を示すレスポンスを送信する。
複数の仮想マシン331,332,・・・には、運用中のものと、改善マシンとして利用されるものがある。例えば運用中の仮想マシンは、複数の端末装置31,32,・・・からのリクエストに応じてサービスを提供する。改善マシンには、割り当てリソースの量を変更予定の運用中の仮想マシンの、変更後のリソースと同じ量のリソースが割り当てられる。そして改善マシンは、変更後のリソース量で、サービスの要求品質が満たせるかどうかの検証に利用される。
このようなシステムにおいて、監視部120により、複数の仮想マシン331,332,・・・のリソース量の追加または削除が管理される。例えば監視部120は、ロードバランサ200から、リクエスト量とレスポンスタイムの計測結果を取得し、取得した計測結果をリクエスト監視テーブル111に記録する。そして監視部120は、過去に取得した計測結果と直近の計測結果とから、仮想マシンに対するリクエスト量の変動率を算出する。
さらに監視部120は、サーバ300上で作動するハイパーバイザ320から、仮想マシンのリソースの種別ごとのリソース使用率を示す使用リソース情報を取得する。監視部120は、取得した使用リソース情報を、リソース優先度テーブル114に記録する。そして監視部120は、リソース種別間のリソース使用率の比較結果から、リソース種別ごとに、リソース変更の優先度を決定する。
監視部120は、リクエスト量の変動率を元に、仮想マシンへの割り当てリソースの削減(コスト改善)、または、割り当てリソースの追加(レスポンス改善)処理を行う。監視部120は、コスト改善またはレスポンス改善の各処理を行う場合、ハイパーバイザ320から、仮想マシンのリソース構成情報を取得する。監視部120は、取得したリソース構成情報を、仮想マシン管理テーブル113に記録する。監視部120は、リソース構成情報を利用して、変更する仮想マシンへの割り当てリソースと変更量とを選定する。変更するリソースの選定は、リソース変更の優先度(順位)に基づき決定される。監視部120は、決定に基づいて、サーバ300内のハイパーバイザ320へ、仮想マシンに割り当てるリソース量の変更を指示する。
なお、図4に示した各要素の機能は、例えば、その要素に対応するプログラムモジュールをコンピュータに実行させることで実現することができる。
以下、図5〜図9を参照し、各装置に記憶される情報について詳細に説明する。
図5は、リクエスト監視テーブルの一例を示す図である。リクエスト監視テーブル111には、インターバル期間、リクエスト量、レスポンスタイム、変動率、コスト改善、およびレスポンス改善の欄が設けられている。
インターバル期間の欄には、リクエスト量計測の単位間隔であるインターバル期間が設定される。図5の例では、インターバル期間は「24時間」であり、24時間ごとのリクエスト量が計測される。リクエスト量の欄は、前回と新規との欄に分かれている。リクエスト量の前回の欄には、前回のリクエスト量の計測時に計測されたリクエストの数が設定される。リクエスト量の新規の欄には、リクエスト量の最後の計測時に計測されたリクエストの数が設定される。レスポンスタイムの欄には、新規のリクエスト量の計測期間内でのレスポンスタイムの代表値(例えば平均値)が設定される。変動率の欄には、リクエスト量の変動率Rが設定される。変動率Rは、新規のリクエスト量を前回のリクエスト量で除算した値である。コスト改善の欄には、コスト改善処理を実行するか否かが設定される。例えば変動率がコスト改善の閾値(図5の例では「0.5」)未満の場合、コスト改善処理が実行される。レスポンス改善の欄には、レスポンス改善処理を実行するか否かが設定される。例えば変動率がレスポンス改善の閾値(図5の例では「1.5」)より大きい場合、レスポンス改善処理が実行される。
図6は、リソース管理テーブルの一例を示す図である。リソース管理テーブル112には、リソース、Min、Max、増減単位、リソース単価、および優先度の欄が設けられている。
リソースの欄には、リソースの種別が設定される。Minの欄には、仮想マシンに割り当て可能なリソースの量の最小値が設置される。Maxの欄には、仮想マシンに割り当て可能なリソースの量の最大値が設定される。なお、ストレージ装置の場合、リソースの量に代えて、ストレージ装置のタイプ別のランクが設定される。ストレージのタイプとして、例えば「タイプ1」〜「タイプ5」の5つのタイプが設けられる。タイプの右の数値がランクを示し、ランクを示す数値が小さいほどリソース量が少ないものとみなされる。例えば「タイプ1」のストレージ装置は、ハードディスクにより、RAID(Redundant Arrays of Inexpensive Disks)5のニアラインのストレージシステムである。「タイプ2」のストレージ装置は、ディスクの回転数が1万回転のハードティスクによる、RAID5のストレージシステムである。「タイプ3」のストレージ装置は、ディスクの回転数が1万回転のハードティスクによる、RAID1のストレージシステムである。「タイプ4」のストレージ装置は、SSDによる、RAID5のストレージシステムである。「タイプ5」のストレージ装置は、SSDによる、RAID1のストレージシステムである。
増減単位の欄には、リソースの量を増減させる際の、増減可能な最小の単位が設置される。例えばメモリであれば、2GB単位で増減させることができる。またCPUであれば、2つのCPUコア(2コア)単位で増減させることができる。ストレージ装置であれば、ランクを1段階ずつ変更することができる。
リソース単価の欄には、増減単位分のリソースの1ヶ月の使用量が設定される。例えば仮想マシンに割り当てるメモリを2GB増加させた場合、その仮想マシンを使用しているユーザが余分に支払う使用料は、$80である。また仮想マシンに割り当てるCPUコア数を2つ増加させた場合、その仮想マシンを使用しているユーザが余分に支払う使用料は、$100である。さらに、仮想マシンに割り当てるストレージ装置のランクを1だけ高くした場合、その仮想マシンを使用しているユーザが余分に支払う使用料は、$40である。
優先度の欄には、仮想マシンにリソースを追加または削除する際の、追加または削除の対象となるリソースの優先度である。最も優先度が高いリソースの優先度の欄には「High(高)」と設定され、次に優先度が高いリソースの優先度の欄には「Mid(中)」と設定され、最も優先度が低いリソースの優先度の欄には「Low(低)」と設定される。図6の例では、メモリが最も優先度が高く、次にCPUの優先度が高く、ストレージ装置の優先度が最も低い。
図7は、仮想マシン管理テーブルの一例を示す図である。仮想マシン管理テーブル113には、仮想マシン、目的、リソース構成、利用コスト、およびレスポンスタイムの欄が設けられている。
仮想マシンの欄には、サーバ300内で動作している仮想マシンの名称が設定される。目的の欄には、仮想マシンの使用の目的が設定される。目的としては、「運用」、「コスト改善」、「レスポンス改善」がある。目的「運用」は、サービスの運用に利用する仮想マシンであることを示している。目的「コスト改善」は、コスト改善のための性能評価に用いる改善マシンとして仮想マシンを利用することを示している。目的「レスポンス改善」は、レスポンス改善のための性能評価に用いる改善マシンとして仮想マシンを利用することを示している。
リソース構成の欄には、仮想マシンに割り当てられているリソースの量が設定される。例えばリソース構成の欄には、CPU、メモリ、ストレージ装置それぞれのリソース量が設定される。
利用コストの欄には、仮想マシンの1月当たりの利用料が設定される。利用コストは、仮想マシンに割り当てられたリソースの量に基づいて算出される。
レスポンスタイムの欄には、仮想マシンのレスポンスタイムに関する情報が設定される。レスポンスタイムに関する情報としては、基準値、安全係数、計測値、および判定結果が含まれる。基準値(Cr)は、仮想マシンに要求されるレスポンスタイムである。安全係数(k)は、レスポンスタイムが基準値を超えないようにするためのレスポンスタイムの閾値の算出に使用する1以下の定数である。基準値に安全係数を乗算した値が、レスポンスタイムの閾値(k×Cr)となる。図7の例では、基準値(Cr)が「5ms」であり、安全係数が「0.85」であるため、「4.25ms(=0.85×5)」が閾値となる。
計測値(RT)の欄には、仮想マシンのレスポンスタイムの計測結果(例えば所定期間内に計測したレスポンスタイムの平均値)が設定される。判定結果の欄には、仮想マシンのレスポンスタイムと閾値との比較結果が設定される。図7の例では、仮想マシン「VM A」は、計測値が閾値より小さいため、判定結果は「OK」となっている。仮想マシン「VM B」は、計測値が閾値以上であるため、判定結果は「NG」となっている。仮想マシン「VM C」は、計測値が閾値より小さいため、判定結果は「OK」となっている。
図8は、リソース優先度テーブルの一例を示す図である。リソース優先度テーブル114には、リソース、リソース使用率:平均値、リソース使用率:最大値、およびリソース変更の優先度判定値の欄が設けられている。
リソースの欄には、リソースの種別が設定される。
リソース使用率:平均値の欄内には、さらに使用率、順位(PA)、および係数(kA)の欄が設けられている。リソース使用率:平均値の使用率の欄には、対応するリソースの仮想マシンでの所定期間内の使用率の平均値が設定される。リソース使用率:平均値の順位の欄には、複数のリソースを使用率の平均値が高い順に並べたときの、対応するリソースの順位(PA)が設定される。リソース使用率:平均値の係数の欄には、対応するリソースの変更の優先度判定値を計算する際の、使用率の平均値の順位に対する重みを示す係数(kA)が設定される。
リソース使用率:最大値の欄内には、さらに使用率、順位(PM)、および係数(kM)の欄が設けられている。リソース使用率:最大値の使用率の欄には、対応するリソースの仮想マシンでの所定期間内の使用率の最大値が設定される。リソース使用率:最大値の順位の欄には、複数のリソースを使用率の最大値が高い順に並べたときの、対応するリソースの順位(PM)が設定される。リソース使用率:最大値の係数の欄には、対応するリソースの変更の優先度判定値を計算する際の、使用率の最大値の順位に対する重みを示す係数(kM)が設定される。
リソース変更の優先度判定値の欄には、対応するリソースの量の変更の優先度判定値が設定される。優先度判定値は、例えば「PA×kA+PM×kM」で計算される値である。優先度判定値の値が小さいリソースほど、リソース量を変更する優先度が高くなる。例えばリソースの種別が3つの場合、優先度判定値が小さい順にリソースを並べたとき、最初のリソースの優先度は「High(高)」となり、2番目のリソースの優先度は「Mid(中)」、3番目のリソースの優先度は「Low(低)」となる。
なお、各リソースの平均値または最大値の係数は、リソースの性質に基づいて、ユーザにより予め決定されている。例えばメモリは、メモリに格納するデータがメモリ容量を超えても、スワップなどの技術で対処可能であるため、メモリは最大限利用されることが多い。すなわち、メモリの使用率の最大値は、100%近いことが多く、そのような状態であっても、仮想マシンが過負荷であるとは判断できない。そのため図8の例では、メモリの使用率の最大値に対する係数は、他のリソースよりも高く設定されている。これにより、リソース使用率の最大値に関するメモリの使用率の順位が高くても、優先度判定値が多めに見積もられる。
またストレージ装置は、コスト改善またはレスポンス改善を実現するには、ストレージの種別を変えることとなる。例えば仮想マシンに割り当てるストレージ装置が、RAID5のストレージ装置からRAID1のストレージ装置に変更される。このようなストレージの種別の変更処理は、データの移動を伴い、時間がかかる。そのため図8の例では、ストレージ装置についてのリソース使用率の平均値に対数する係数は、他のリソースよりも高く設定されている。これにより、リソース使用率の平均値に関するストレージ装置の使用率の順位が高くても、優先度判定値が多めに見積もられる。
図9は、ロードバランサが記憶するリクエスト管理テーブルの一例を示す図である。リクエスト管理テーブル211には、受信時刻、リクエスト、転送先仮想マシン、およびレスポンスタイムの欄が設けられている。
受信時刻の欄には、端末装置31,32,・・・から受信したリクエストの受信時刻が設定される。リクエストの欄には、受信したリクエストの内容が設定される。転送先仮想マシンの欄には、リクエストの転送先の仮想マシンの名称が設定される。レスポンスタイムの欄には、リクエストを仮想マシンに転送してから、その仮想マシンからレスポンスが返されるまでの時間(レスポンスタイム)が設定される。
次に、リソース量の自動変更処理について詳細に説明する。リソース量の自動変更処理は、大別するとリクエスト監視処理と最適化処理(コスト改善またはレスポンス改善処理)とに分けられる。以下、図10と図11とを参照して、リクエスト監視処理と最適化処理との概略を説明する。
図10は、リクエスト監視処理の手順の一例を示すシーケンス図である。リクエスト監視処理では、まず仮想マシン監視装置100は、サーバ300へ、運用中の仮想マシンのスナップショット生成指示を送信する(ステップS101)。スナップショット生成指示を受信したサーバ300は、仮想マシンのスナップショットを生成する(ステップS102)。
次に仮想マシン監視装置100は、リクエスト量・レスポンスタイム計測指示を、ロードバランサ200に送信する(ステップS103)。ロードバランサ200は、リクエスト量・レスポンスタイム計測指示に応じて、サーバ300内の運用中の仮想マシンに転送したリクエスト量を計数し、各リクエストに対するレスポンスタイムの平均値を計算する(ステップS104)。そしてロードバランサ200は、リクエスト量とレスポンスタイムの平均値とを、計測結果として仮想マシン監視装置100に送信する(ステップS105)。
次に仮想マシン監視装置100は、運用中の仮想マシンのリソース使用率の要求を、サーバ300に送信する(ステップS106)。サーバ300は、仮想マシン監視装置100からの要求に応じて、仮想マシンのリソース利用率の情報を応答する(ステップS107)。例えばサーバ300では、仮想マシン331,332,・・・それぞれのOSが、リソース使用率を計測している。そしてハイパーバイザ320が、仮想マシン監視装置100からの要求に応じて、仮想マシン331,332,・・・それぞれのOSからリソース使用率の情報を取得し、仮想マシン監視装置100に送信する。
仮想マシン監視装置100は、仮想マシンのリソース使用率の情報に基づいて、リソースごとに優先度判定値を算出し、リソース変更の優先度を決定する(ステップS108)。次に仮想マシン監視装置100は、リクエスト量に基づいて、リクエスト量の変動率を算出する(ステップS109)。そして仮想マシン監視装置100は、取得した情報を解析し、最適化処理(コスト改善処理またはレスポンス改善処理)を選択する。
図11は、最適化処理の手順の一例を示すシーケンス図である。最適化処理では、仮想マシン監視装置100は、運用中の仮想マシン(運用マシン)に割り当てられたリソースの構成の情報を、サーバ300に要求する(ステップS121)。するとサーバ300は、運用マシンに割り当てたリソースの構成を示す情報を、仮想マシン監視装置100に送信する(ステップS122)。
仮想マシン監視装置100は、運用マシンに割り当てられたリソース量を格納する(ステップS123)。次に仮想マシン監視装置100は、運用マシンの最適なリソース量を決定する(ステップS124)。そして仮想マシン監視装置100は、サーバ300に対して改善マシンの生成を指示する(ステップS125)。サーバ300は、指示に従って改善マシンとして使用する仮想マシンを生成する(ステップS126)。
次に仮想マシン監視装置100は、サーバ300へ、改善マシンへのスナップショット適用指示を送信する(ステップS127)。サーバ300は、指示に従って、運用マシンのスナップショットを改善マシンで復元する(ステップS128)。続けて、仮想マシン監視装置100は、サーバ300へ、ステップS124で決定した最適なリソース量を改善マシンに割り当てるように、改善マシンのリソース量変更指示を送信する(ステップS129)。サーバ300は、指示に従って改善マシンに割り当てるリソースの量を変更する(ステップS130)。
仮想マシン監視装置100は、ロードバランサ200に対して、改善マシンのレスポンスタイム計測指示を送信する(ステップS131)。ロードバランサ200は、過去に運用サーバに送信したリクエストのログを記録しており、仮想マシン監視装置100からのレスポンスタイム計測指示に応じて、記録しておいたリクエストを改善マシン宛てに送信する(ステップS132)。サーバ300では、改善マシンにより、リクエストに応じた処理が実行される。そしてサーバ300内の改善マシンは、ロードバランサ200にリクエストに対する応答を送信する(ステップS133)。ロードバランサ200は、リクエストの送信から応答までの時間を計測し、計測結果をレスポンスタイムとする。ロードバランサ200は、レスポンスタイムの計測結果を、仮想マシン監視装置100に送信する(ステップS134)。
仮想マシン監視装置100は、改善マシンのレスポンスタイムが、運用マシンに求められるレスポンスタイムの要件を満たしているか否かを判定する(ステップS135)。仮想マシン監視装置100は、レスポンスタイムの要件が満たされると判定した場合、サーバ300に対して、運用マシンのリソース量を、ステップS124で決定した最適なリソース量に変更するように指示する(ステップS136)。サーバ300は、指示に従って運用マシンのリソース量を変更する(ステップS137)。
このようにして、運用マシンのリソース量が自動で変更される。
次に、各装置が実行する処理を詳細に説明する。
図12は、仮想マシン監視装置におけるリクエスト監視処理の手順の一例を示すフローチャートの前半である。以下、図12に示す処理をステップ番号に沿って説明する。
[ステップS201]監視部120は、各種データテーブルを生成する。具体的には、監視部120は、リクエスト監視テーブル111、リソース管理テーブル112、およびリソース優先度テーブル114を新たに生成する。この時点では、リクエスト監視テーブル111には、インターバル期間のみが設定されている。インターバル期間は、リクエスト量を計数する期間である。インターバル期間は、ユーザにより予め指定されている。
なお、過去に実行したリクエスト監視処理により、リクエスト監視テーブル111とリソース管理テーブル112とリソース優先度テーブル114とが生成済みの場合、ステップS201の処理は省略される。
[ステップS202]監視部120は、各種データテーブルに設定するデータの入力を受け付ける。例えば監視部120は、リソース管理テーブル112の各欄(図6参照)のうち、リソース、Min、Max、増減単位、リソース単価の欄に設定するデータの入力を受け付ける。そして監視部120は、ユーザにより入力されたデータを、リソース管理テーブル112に設定する。また監視部120は、リソース優先度テーブル114の各欄(図8参照)のうち、リソース使用率:平均値の係数の欄とリソース使用率:最大値の係数の欄とに設定する値の入力を受け付ける。そして監視部120は、ユーザにより入力されたデータを、リソース優先度テーブル114に設定する。
[ステップS203]監視部120は、ロードバランサ200内の負荷計測部230およびサーバ300内のハイパーバイザ320それぞれとの間で、管理ネットワーク20を介して通信を接続する。
[ステップS204]監視部120は、サーバ300内のハイパーバイザ320に対して、運用中の仮想マシンのスナップショット作成を指示する。
[ステップS205]監視部120は、ロードバランサ200内の負荷計測部230に対して、リクエスト量とレスポンスタイムとの計測指示を送信する。この計測指示に応じて、負荷計測部230において運用中の仮想マシンへのリクエストが監視され、リクエスト量とレスポンスタイムとの計測が開始される。
[ステップS206]監視部120は、所定時間待機する。待機する所定時間は、ユーザにより予め設定されている。
[ステップS207]監視部120は、ロードバランサ200内の負荷計測部230に対して、リクエスト量の監視終了と同時にリクエスト情報の計測終了を指示する。計測終了指示に応じて、負荷計測部230から、計測結果が応答される。計測結果には、例えば仮想マシンに所定期間内に送信したリクエスト量と、その期間の平均のレスポンスタイムとが含まれる。
[ステップS208]監視部120は、応答された計測結果に基づいて、リクエスト監視テーブル111を更新する。例えば監視部120は、最新の計測結果に含まれるリクエスト量を、リクエスト監視テーブル111のリクエスト量の新規の欄に設定する。この際、新規の欄に、前回の計測結果に示されていたリクエスト量が設定されている場合、そのリクエスト量を、リクエスト量の前回の欄にコピーした後に、新規の欄に最新のリクエスト量を書き込む。また監視部120は、最新の計測結果に含まれるレスポンスタイムを、リクエスト監視テーブル111のレスポンスタイムの欄に設定する。また監視部120は、新規のリクエスト量を前回のリクエスト量で除算することで、変動率を算出し、リクエスト監視テーブル111の変動率の欄に設定する。
[ステップS209]監視部120は、リクエスト監視テーブル111に前回のリクエスト量が設定されているか否かを判断する。監視部120は、前回のリクエスト量が設定されている場合、処理をステップS210に進める。また監視部120は、前回のリクエスト量が設定されていない場合、処理をステップS205に進める。
[ステップS210]監視部120は、仮想マシンのリソース使用率に関する情報を、サーバ300内のハイパーバイザ320に要求する。この要求に応じて、ハイパーバイザ320から、リソース使用率に関する情報が応答される。リソース使用率に関する情報には、CPU、メモリ、ストレージ装置それぞれの使用率の平均値と最大値とが含まれる。
[ステップS211]監視部120は、リソース使用率に関する情報に基づいて、リソース優先度テーブル114を更新する。例えば、監視部120は、リソース優先度テーブル114のリソース使用率:平均値の使用率の欄に、各リソースの使用率の平均値を設定し、リソース優先度テーブル114のリソース使用率:最大値の使用率の欄に、各リソースの使用率の最大値を設定する。監視部120は、その後、処理をステップS221(図13参照)に進める。
図13は、仮想マシン監視装置におけるリクエスト監視処理の手順の一例を示すフローチャートの後半である。以下、図13に示す処理をステップ番号に沿って説明する。
[ステップS221]監視部120は、各リソースのリソース使用率の順位を決定する。例えば監視部120は、リソース優先度テーブル114を参照し、まず、リソース使用率:平均値の使用率の欄に設定されている各リソースの使用率を比較し、使用率の高い順に順位を決定する。そして監視部120は、リソース使用率の平均値の順位を、リソース優先度テーブル114のリソース使用率:平均値の順位の欄に、各リソースに対応付けて設定する。次に監視部120は、リソース優先度テーブル114のリソース使用率:最大値の欄に設定されている各リソースの使用率を比較し、使用率の高い順に順位を決定する。そして監視部120は、リソース使用率の最大値の順位を、リソース優先度テーブル114のリソース使用率:最大値の順位の欄に、各リソースに対応付けて設定する。
[ステップS222]監視部120は、リソースごとに、リソース変更の優先度を決定する。例えば監視部120は、使用率の平均値の順位(PA)に係数(kA)を乗算した値と、使用率の最大値の順位(PM)に係数(kM)を乗算した値との加算結果を、リソース変更の優先度判定値とする。監視部120は、各リソースについて算出したリソース変更の優先度判定値を、リソース優先度テーブル114のリソース変更の優先度判定値の欄に設定する。
さらに監視部120は、各リソースのリソース変更の優先度判定値に基づいて、各リソースの優先度を決定し、リソース管理テーブル112の優先度の欄に設定する。例えば監視部120は、リソース変更の優先度判定値が最も高いリソースの優先度を「High」、リソース変更の優先度判定値が2番目に高いリソースの優先度を「Mid」、リソース変更の優先度判定値が最も低いリソースの優先度を「Low」とする。
[ステップS223]監視部120は、レスポンスタイムが閾値以上か否かを判断する。閾値は、仮想マシン管理テーブル113に設定されている基準値×安全係数である。監視部120は、レスポンスタイムが閾値以上の場合、処理をステップS228に進める。また監視部120は、レスポンスタイムが閾値未満の場合、処理をステップS224に進める。
[ステップS224]監視部120は、リクエスト監視テーブル111に設定されている変動率に基づいて、リクエスト量の増減の傾向を判定する。例えば監視部120は、変動率が、コスト改善の閾値(例えば「0.5」)未満の場合、リクエスト量が減少傾向にあると判定し、リクエスト監視テーブル111の”コスト改善の欄に「Yes」を書き込む。また監視部120は、変動率が、コスト改善の閾値以上の場合、リクエスト量が減少傾向にはないと判定し、リクエスト監視テーブル111のコスト改善の欄に「No」を書き込む。さらに監視部120は、変動率が、レスポンス改善の閾値(例えば「1.5」)より大きい場合、リクエスト量が増加傾向にあると判定し、リクエスト監視テーブル111のレスポンス改善の欄に「Yes」を書き込む。また監視部120は、変動率が、レスポンス改善の閾値以下の場合、リクエスト量が増加傾向にはないと判定し、リクエスト監視テーブル111のレスポンス改善の欄に「No」を書き込む。
[ステップS225]監視部120は、リクエスト監視テーブル111のコスト改善のステータスを照会する。例えば監視部120は、コスト改善の欄に「Yes」が設定されている場合、処理をステップS227に進める。監視部120は、コスト改善の欄に「No」が設定されている場合、処理をステップS226に進める。
[ステップS226]監視部120は、リクエスト監視テーブル111のレスポンス改善のステータスを照会する。監視部120は、レスポンス改善の欄に「Yes」が設定されている場合、処理をステップS228に進める。監視部120は、レスポンス改善の欄に「No」が設定されている場合、処理をステップS205(図12参照)に進める。
[ステップS227]監視部120は、コスト改善処理を行う。コスト改善処理の詳細は後述する(図15、図16参照)。監視部120は、コスト改善処理が終了すると、リクエスト監視処理を終了する。
[ステップS228]監視部120は、レスポンス改善処理を行う。レスポンス改善処理の詳細は後述する(図17、図18参照)。監視部120は、コスト改善処理が終了すると、リクエスト監視処理を終了する。
このようにして、リクエストを監視して、リクエスト量が急増していればレスポンス改善処理が行われ、リクエスト量が急減していればコスト改善処理が行われる。
ここで、コスト改善処理とレスポンス改善処理の詳細を説明する前に、ロードバランサ200によるリクエスト量・レスポンスタイム計測処理について詳細に説明する。
図14は、リクエスト量・レスポンスタイム計測処理の手順の一例を示すフローチャートである。なおリクエスト量の監視処理は、仮想マシン監視装置100内の監視部120からリクエスト量・レスポンスタイム計測指示を受信したときに実行される。以下、図14に示す処理をステップ番号に沿って説明する。
[ステップS301]ロードバランサ200の負荷計測部230は、負荷分散制御部220による負荷分散処理を監視し、端末装置31,32,・・・からのリクエストを仮想マシン331,332,・・・に転送したか否かを判断する。負荷計測部230は、リクエストの転送があった場合、処理をステップS302に進める。また負荷計測部230は、リクエストの転送がなければ、処理をステップS304に進める。
[ステップS302]負荷計測部230は、転送したリクエストに関するリクエスト情報を、リクエスト管理テーブル211に登録する。
[ステップS303]負荷計測部230は、転送したリクエストに対応する仮想マシンからの応答を待ち、そのリクエストに対するレスポンスタイムを計測する。そして負荷計測部230は、計測したレスポンスタイムを、ステップS302で登録したリクエスト情報に関連付けて、リクエスト管理テーブル211のレスポンスタイムの欄に設定する。
[ステップS304]負荷計測部230は、仮想マシン監視装置100内の監視部120から、計測終了指示を受信したか否かを判断する。負荷計測部230は、計測終了指示を受信した場合、処理をステップS305に進める。また負荷計測部230は、計測終了指示を受信していなければ、処理をステップS301に進める。
[ステップS305]負荷計測部230は、リクエスト管理テーブル211に格納したリクエスト情報に基づいて、リクエスト量を計数する。例えば負荷計測部230は、リクエスト量・レスポンスタイム計測指示を受信後、計測終了指示を受信するまでの期間内の時刻が受信時刻に設定されており、転送先仮想マシンが運用中の仮想マシンであるリクエストのリクエスト情報を特定する。そして負荷計測部230は特定したリクエスト情報の数を計数し、運用中の仮想マシンへのリクエスト量とする。
[ステップS306]負荷計測部230は、レスポンスタイムの平均値を計算する。例えばステップS305で特定したリクエスト情報それぞれのレスポンスタイムを合計し、合計をリクエスト量で除算した結果を、レスポンスタイムの平均値とする。
[ステップS307]負荷計測部230は、リクエスト量とレスポンスタイムの平均値とを、計測結果として仮想マシン監視装置100の監視部120に送信する。
このように、ロードバランサ200において計測されたリクエスト量とレスポンスタイム(平均値)とに基づいて、仮想マシン監視装置100においてコスト改善処理またはレスポンス改善処理を実行するか否かが決定され、決定された処理が実行される。
図15は、コスト改善処理の手順の一例を示すフローチャートの前半である。運用中の仮想マシン331のコスト改善処理を実行するものとして、以下、図15に示す処理をステップ番号に沿って説明する。
[ステップS401]仮想マシン監視装置100の監視部120は、仮想マシン331の情報を管理する仮想マシン管理テーブル113を生成する。なお、既に仮想マシン管理テーブル113が生成済みの場合、監視部120は、新たな仮想マシン管理テーブル113の生成は行わない。
例えば監視部120は、仮想マシン管理テーブル113に仮想マシン331のレコードを登録する。この時点では、登録されたレコードには、仮想マシン331の名称「VM A」に対応付けて、目的、利用コスト、レスポンスタイムの基準値・安全係数・判定結果が設定される。このとき設定される目的は「運用」である。レスポンスタイムの基準値・安全係数は、予めユーザにより指定されている値である。レスポンスタイムの計測値は、ロードバランサ200がステップS306(図14参照)で計算したレスポンスタイムの平均値である。レスポンスタイムの平均値は、リクエスト監視テーブル111のレスポンスタイムの欄から取得できる。運用マシンである仮想マシン331のレスポンスタイムの判定は、ステップS223(図13参照)において行われている。監視部120は、ステップS223の判定結果を、仮想マシン管理テーブル113のレスポンスタイムの判定結果の欄に設定する。
なお、過去に実行したリクエスト監視処理により、仮想マシン管理テーブル113が生成済みの場合、ステップS401の処理は省略される。
[ステップS402]監視部120は、ハイパーバイザ320から、仮想マシン331のリソース構成(各リソースの割り当て量)を取得する。そして監視部120は、取得したリソース構成を、仮想マシン管理テーブル113に設定する。
[ステップS403]監視部120は、仮想マシン管理テーブル113に登録されている仮想マシン331のレコードのコピーを、改善マシンとして用いる仮想マシンのレコードとして、仮想マシン管理テーブル113に追加する。そして監視部120は、新たに追加したレコードにおける仮想マシンの名称を変更し、目的の欄に「コスト改善」と設定する。
次に、監視部120は、ステップS404〜S406の処理により、運用中の仮想マシン331に比べてロースペックのリソース構成を、改善マシンとして用いる仮想マシンに設定する。
[ステップS404]監視部120は、仮想マシン管理テーブル113の改善マシンのレコードについて、リソース構成に示される各リソースの割り当て量のうち、優先度の高いリソースの割り当て量から、1単位分だけ減算する。なおリソースの優先度は、リソース管理テーブル112の優先度の欄を参照して判別できる。監視部120は、優先度の高いリソースの減算後の割り当て量を、仮想マシン管理テーブル113の改善マシンのレコードのリソース構成の欄に設定する。なお監視部120は、改善マシンに割り当てられた優先度の高いリソースが、そのリソースの利用可能な最小値の場合、次に優先度の高いリソースの割り当て量から、1単位分だけ減算する。各リソースの利用可能な最小値は、リソース管理テーブル112のMinの欄に設定されている。
図7の仮想マシン管理テーブル113の例では、仮想マシン「VM A」が運用中の仮想マシンである。図6に示したリソース管理テーブル112では、最も優先度が高いのはメモリである。仮想マシン「VM A」に割り当てられたメモリ量は4GBである。そこで監視部120は、仮想マシン管理テーブル113の目的が「コスト改善」の仮想マシン「VM B」のレコードのリソース構成のメモリの欄に、4GBから1単位分(2GB)減算した値「2GB」を書き込む。
ここで、仮に運用中の仮想マシン「VM A」に割り当てられたメモリ容量が2GB(最小値)の場合、次に優先度の高いCPUの割り当て量が1単位分(2コア)だけ減算される。この際、監視部120は、割り当てられたリソース量が最小値で減算できないリソース(メモリ)について、1単位分だけ加算してもよい。
[ステップS405]監視部120は、運用中の仮想マシンの利用コストと、改善マシンの利用コストとを計算する。例えば、監視部120は、リソースごとの増減単価をリソース管理テーブル112から取得する。次に監視部120は、仮想マシン管理テーブル113に示される、仮想マシンへのリソースの割り当て量に増減単価を乗算し、その仮想マシンのリソースごとの利用コストを得る。そして監視部120は、リソースごとの利用コストを合計し、該当仮想マシンの利用コストとする。監視部120は、運用中の仮想マシンの利用コストと、改善マシンの利用コストとのそれぞれについて算出した利用コストを、仮想マシン管理テーブル113の利用コストの欄に設定する。
[ステップS406]監視部120は、改善マシンの方が利用コストが低いかどうかを判定する。監視部120は、改善マシンの方が利用コストが低い場合、処理をステップS411に進める。また監視部120は、運用中のマシンの方が利用コストが低いか、または利用コストが変わらない場合、処理をステップS404に進め、改善マシンのリソース量をさらに削減する。なお図15のフローチャートには示していないが、削減可能なリソースがない場合は、コスト改善処理は終了する。
図16は、コスト改善処理の手順の一例を示すフローチャートの後半である。以下、図16に示す処理をステップ番号に沿って説明する。
[ステップS411]監視部120は、サーバ300のハイパーバイザ320に対し、運用中の仮想マシン331のクローン生成を指示する。ハイパーバイザ320は、指示に従って仮想マシン331のクローンの仮想マシンを生成する。以下、クローンとして仮想マシン332が生成されたものとする。
[ステップS412]監視部120は、ハイパーバイザ320に対し、生成した仮想マシン332へのスナップショットの適用を指示する。この指示に応じて、ハイパーバイザ320は、仮想マシン331のスナップショットを、仮想マシン332に適用する。これにより、仮想マシン331の動作状態が、仮想マシン332で再現される。
[ステップS413]監視部120は、ハイパーバイザ320に対し、運用中の仮想マシン331のクローンである仮想マシン332に割り当てるリソース量の削減を指示する。例えば監視部120は、仮想マシン管理テーブル113の目的「コスト改善」の仮想マシンのリソース構成をハイパーバイザ320に通知し、仮想マシン332のリソース構成を、通知したリソース構成とするようにハイパーバイザ320に指示する。
[ステップS414]監視部120は、ハイパーバイザ320に対し、運用中の仮想マシン331のクローンである仮想マシン332の名称(例えば「VM B」)を指定し、仮想マシン332の起動を指示する。ハイパーバイザ320は、指示に従って、仮想マシン332を起動する。
[ステップS415]監視部120は、ロードバランサ200の負荷計測部230に対し、仮想マシン332の名称「VM B」を指定して、仮想マシン332のレスポンスタイムの計測を指示する。負荷計測部230は、計測指示に応じて、記憶部210に蓄積してあるリクエスト情報に基づいて、リクエストを仮想マシン332に送信し、そのリクエストに対するレスポンスタイムを計測する。例えば負荷計測部230は、複数のリクエストを仮想マシン332に送信し、各リクエストに対するレスポンスタイムの平均値を、仮想マシン332のレスポンスタイムとする。
[ステップS416]監視部120は、負荷計測部230から、仮想マシン332のレスポンスタイムの計測結果を取得する。監視部120は、取得したレスポンスタイムを、仮想マシン管理テーブル113内の目的「コスト改善」のレコードのレスポンスタイムの計測値の欄に設定する。
[ステップS417]監視部120は、仮想マシン332のレスポンスタイムが、運用中の仮想マシン331に求められるレスポンスタイムの閾値(基準値×安全係数)未満か否かを判定する。監視部120は、レスポンスタイムが閾値未満の場合、仮想マシン管理テーブル113内の目的「コスト改善」のレコードのレスポンスタイムの判定結果の欄に「OK」と設定し、処理をステップS418に進める。また監視部120は、レスポンスタイムが閾値以上の場合、仮想マシン管理テーブル113内の目的「コスト改善」のレコードのレスポンスタイムの判定結果の欄に「NG」と設定し、コスト改善処理を終了する。
[ステップS418]監視部120は、サーバ300内のハイパーバイザ320に対し、運用中の仮想マシン331への割り当てリソース量の削減を指示する。例えば監視部120は、仮想マシン管理テーブル113の目的「コスト改善」の仮想マシンのリソース構成をハイパーバイザ320に通知し、運用中の仮想マシン331のリソース構成を、通知したリソース構成とするようにハイパーバイザ320に指示する。
[ステップS419]監視部120は、仮想マシン管理テーブル113における運用中の仮想マシン331のリソース構成を更新する。例えば監視部120は、目的「コスト改善」のレコードのリソース構成のコピーを、目的「運用」のレコードのリソース構成に上書きで書き込む。監視部120は、その後、処理をステップS402に進め、さらにリソース量の削減が可能かどうかを探索する。
このようにして、優先度の高いリソースから順に、運用中の仮想マシン331への割り当てリソース量が削減される。最終的には、運用中の仮想マシン331への割り当てリソース量は、レスポンスタイムの条件が満たされる最小限のリソース量となる。
次に、レスポンス改善処理について詳細に説明する。
図17は、レスポンス改善処理の手順の一例を示すフローチャートの前半である。運用中の仮想マシン331のコスト改善処理を実行するものとして、以下、図17に示す処理をステップ番号に沿って説明する。
[ステップS501]仮想マシン監視装置100の監視部120は、仮想マシン331の情報を管理する仮想マシン管理テーブル113を生成する。なお、過去に実行したリクエスト監視処理により、仮想マシン管理テーブル113が生成済みの場合、ステップS501の処理は省略される。仮想マシン管理テーブル113の生成処理の詳細は、図15のステップS401と同様である。
[ステップS502]ハイパーバイザ320から、仮想マシン331のリソース構成(各リソースの割り当て量)を取得する。そして監視部120は、取得したリソース構成を、仮想マシン管理テーブル113に設定する。
[ステップS503]監視部120は、仮想マシン管理テーブル113に登録されている仮想マシン331のレコードのコピーを、改善マシンとして用いる仮想マシンのレコードとして、仮想マシン管理テーブル113に追加する。そして監視部120は、新たに追加したレコードにおける仮想マシンの名称を変更し、目的の欄に「レスポンス改善」と設定する。
[ステップS504]監視部120は、仮想マシン管理テーブル113の改善マシンのレコードについて、リソース構成に示される各リソースの割り当て量のうち、優先度の高いリソースの割り当て量に、1単位分だけ加算する。監視部120は、優先度の高いリソースの加算後の割り当て量を、仮想マシン管理テーブル113の改善マシンのレコードのリソース構成の欄に設定する。なお監視部120は、改善マシンに割り当てられた優先度の高いリソースが、そのリソースの利用可能な最大値の場合、次に優先度の高いリソースの割り当て量に、1単位分だけ加算する。各リソースの利用可能な最大値は、リソース管理テーブル112のMaxの欄に設定されている。
例えば、優先度が最も高いリソースがメモリであり、運用中の仮想マシンに割り当てられたメモリ量が2GBの場合、目的「レスポンス改善」の仮想マシンのメモリ量には、1単位(2GB)分加算した、4GBとなる。
また、運用中の仮想マシンに割り当てられたメモリの量が64GB(最大値)の場合、次に優先度の高いリソースであるCPUの割り当て量が1単位(2コア)分を加算される。この際、リソース使用量が最大値となっているリソース(メモリ)についての割り当て量を、1単位分だけ減算してもよい。
リソース量の増加処理後、監視部120は、処理をステップS511(図18参照)に進める。
図18は、レスポンス改善処理の手順の一例を示すフローチャートの後半である。以下、図18に示す処理をステップ番号に沿って説明する。
[ステップS511]監視部120は、サーバ300のハイパーバイザ320に対し、運用中の仮想マシン331のクローン生成を指示する。ハイパーバイザ320は、指示に従って仮想マシン331のクローンの仮想マシンを生成する。以下、クローンとして仮想マシン332が生成されたものとする。
[ステップS512]監視部120は、ハイパーバイザ320に対し、生成した仮想マシン332へのスナップショットの適用を指示する。この指示に応じて、ハイパーバイザ320は、仮想マシン331のスナップショットを、仮想マシン332に適用する。これにより、仮想マシン331の動作状態が、仮想マシン332で再現される。
[ステップS513]監視部120は、ハイパーバイザ320に対し、運用中の仮想マシン331のクローンである仮想マシン332に割り当てるリソース量の増強を指示する。例えば監視部120は、仮想マシン管理テーブル113の目的「レスポンス改善」の仮想マシンのリソース構成をハイパーバイザ320に通知し、仮想マシン332のリソース構成を、通知したリソース構成とするようにハイパーバイザ320に指示する。
[ステップS514]監視部120は、ハイパーバイザ320に対し、運用中の仮想マシン331のクローンである仮想マシン332の名称(例えば「VM C」)を指定し、仮想マシン332の起動を指示する。ハイパーバイザ320は、指示に従って、仮想マシン332を起動する。
[ステップS515]監視部120は、ロードバランサ200の負荷計測部230に対し、仮想マシン332の名称「VM C」を指定して、仮想マシン332のレスポンスタイムの計測を指示する。負荷計測部230は、計測指示に応じて、記憶部210に蓄積してあるリクエスト情報に基づいて、リクエストを仮想マシン332に送信し、そのリクエストに対するレスポンスタイムを計測する。例えば負荷計測部230は、複数のリクエストを仮想マシン332に送信し、各リクエストに対するレスポンスタイムの平均値を、仮想マシン332のレスポンスタイムとする。
[ステップS516]監視部120は、負荷計測部230から、仮想マシン332のレスポンスタイムの計測結果を取得する。監視部120は、取得したレスポンスタイムを、仮想マシン管理テーブル113内の目的「レスポンス改善」のレコードのレスポンスタイムの計測値の欄に設定する。
[ステップS517]監視部120は、仮想マシン332のレスポンスタイムが、運用中の仮想マシン331に求められるレスポンスタイムの閾値(基準値×安全係数)未満か否かを判定する。監視部120は、レスポンスタイムが閾値未満の場合、仮想マシン管理テーブル113内の目的「レスポンス改善」のレコードのレスポンスタイムの判定結果の欄に「OK」と設定し、処理をステップS518に進める。また監視部120は、レスポンスタイムが閾値以上の場合、仮想マシン管理テーブル113内の目的「レスポンス改善」のレコードのレスポンスタイムの判定結果の欄に「NG」と設定し、処理をステップS504(図17参照)に進める。
[ステップS518]監視部120は、サーバ300内のハイパーバイザ320に対し、運用中の仮想マシン331への割り当てリソース量の増強を指示する。例えば監視部120は、仮想マシン管理テーブル113の目的「レスポンス改善」の仮想マシンのリソース構成をハイパーバイザ320に通知し、運用中の仮想マシン331のリソース構成を、通知したリソース構成とするようにハイパーバイザ320に指示する。
[ステップS519]監視部120は、仮想マシン管理テーブル113における運用中の仮想マシン331のリソース構成を更新する。例えば監視部120は、目的「レスポンス改善」のレコードのリソース構成のコピーを、目的「運用」のレコードのリソース構成に上書きで書き込む。
このようにして、仮想マシンに対するリクエストの量の変化に応じて、仮想マシンに割り当てるリソースの量を変更することができる。例えば仮想マシンに対するリクエストの量が増加傾向にあれば、レスポンスタイムが悪化するのを待たずに、仮想マシンに割り当てるリソースの量を増加させることができる。その結果、仮想マシンのリソースの量の変更の遅延を抑止することができる。すなわち仮想マシンのレスポンスタイムが悪化したことを検知してから、その仮想マシンに割り当てるリソースの量を変更する場合に比べ、迅速にリソースの量を変更できる。その結果、仮想マシンの過負荷によりレスポンスタイムが悪化することが抑止される。
また仮想マシンに対するリクエストの量が減少傾向にあれば、仮想マシンに割り当てるリソースの量を減少させることができる。その結果、仮想マシンに過大にリソースを割り当ててしまうことを抑止し、システム全体のリソースの有効活用が可能となる。しかも、仮想マシンを使用しているユーザが、仮想マシンに割り当てられたリソース量に応じて費用を支払っている場合、リソースの量を最小限に抑えることで、仮想マシンの使用コストを低減させることができる。
また第2の実施の形態では、運用中の仮想マシンに割り当てるリソースの量を変更する前に、改善マシンによって、レスポンスタイムに関する条件が満たされることを確認している。これにより、割り当てるリソースの量が過剰に削減されることが抑止されている。
さらに第2の実施の形態では、リソースの種別ごとに、そのリソースの使用率に応じて、リソースの量を変更する際の優先度が定められている。そして優先度が高い種別のリソースから優先的にリソースの量の変更が決定され、改善マシンを用いてレスポンスタイムの条件が検証される。これにより、性能悪化の原因となる可能性の高い種別のリソースから順に、そのリソースを変更した場合のレスポンスタイムを検証でき、検証処理を効率的に行うことができる。
〔その他の実施の形態〕
第2の実施の形態では、リクエストとレスポンスとを中継するロードバランサが、リクエスト量とレスポンスタイムとを計測しているが、他の方法でリクエスト量とレスポンスタイムとを計測することもできる。例えば仮想マシン監視装置100が、業務ネットワーク41を介して通信されるパケットをキャプチャし、キャプチャしたパケットを解析して、特定の仮想マシンに関するリクエスト量とレスポンスタイムとを計測することもできる。
以上、実施の形態を例示したが、実施の形態で示した各部の構成は同様の機能を有する他のものに置換することができる。また、他の任意の構成物や工程が付加されてもよい。さらに、前述した実施の形態のうちの任意の2以上の構成(特徴)を組み合わせたものであってもよい。
1a,1b 端末装置
2 ネットワーク
3 サーバ
3a−1,3a−2,・・・ CPU
3b−1,3b−2,・・・ メモリ
3c 仮想マシン
10 情報処理装置
11 記憶部
12 処理部

Claims (8)

  1. サーバが実行している仮想マシンに送信された単位期間当たりのリクエストの量を監視し、前記リクエストの量の時系列での変化度合いに基づいて、前記仮想マシンの実行に使用可能なハードウェアリソースの量を変更するか否かを決定し、変更すると決定した場合、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量の変更を、前記サーバに指示する処理部、
    を有する情報処理装置。
  2. 前記処理部は、
    変更するか否かの決定では、直近の第1の単位期間での前記リクエストの量を、前記第1の単位期間の直前の第2の単位期間での前記リクエストの量と比較したときの変化度合いが閾値を超えている場合、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量を変更すると決定する、
    請求項1記載の情報処理装置。
  3. 前記処理部は、
    変更するか否かの決定では、前記第1の単位期間での前記リクエストの量が、前記第2の単位期間での前記リクエストの量よりも減少しており、減少の度合いが第1の閾値を超えている場合、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量を減少させることを決定し、
    前記サーバへの指示では、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量を減少させることを、前記サーバに指示する、
    請求項2記載の情報処理装置。
  4. 前記処理部は、
    変更するか否かの決定では、前記第1の単位期間での前記リクエストの量が、前記第2の単位期間での前記リクエストの量よりも増加しており、増加の度合いが第2の閾値を超えている場合、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量を増加させることを決定し、
    前記サーバへの指示では、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量を増加させることを、前記サーバに指示する、
    請求項2または3記載の情報処理装置。
  5. 前記処理部は、
    前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量を増加させると決定した場合、前記ハードウェアリソースの種別ごとに、前記仮想マシンの実行に使用可能とする量の変更の優先度、前記仮想マシンの実行に使用可能とする量の最小値、および前記仮想マシンの実行に使用可能とする量の最大値が示されたリソース管理情報に基づいて、優先度が最も高い種別の前記ハードウェアリソースを、最大値を超えない範囲で増加させることを決定し、
    前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量を減少させると決定した場合、前記リソース管理情報に基づいて、優先度が最も高い種別の前記ハードウェアリソースを、最小値を下回らない範囲で減少させることを決定する、
    請求項1ないし4のいずれかに記載の情報処理装置。
  6. 前記処理部は、
    前記サーバから前記ハードウェアリソースの種別ごとの前記仮想マシンの使用率を取得し、使用率が高い種別の前記ハードウェアリソースほど高い優先度を、前記リソース管理情報に設定する、
    請求項5記載の情報処理装置。
  7. コンピュータに、
    サーバが実行している仮想マシンに送信された単位期間当たりのリクエストの量を監視し、
    前記リクエストの量の時系列での変化度合いに基づいて、前記仮想マシンの実行に使用可能なハードウェアリソースの量を変更するか否かを決定し、
    変更すると決定した場合、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量の変更を、前記サーバに指示する、
    処理を実行させる仮想マシン監視プログラム。
  8. 仮想マシンを実行しているサーバと、
    端末装置から送信されたリクエストを前記仮想マシンに転送し、前記仮想マシンに転送した単位期間当たりのリクエストの量を計数する中継装置と、
    前記仮想マシンに転送した単位期間当たりのリクエストの量を前記中継装置から取得し、前記リクエストの量の時系列での変化度合いに基づいて、前記仮想マシンの実行に使用可能なハードウェアリソースの量を変更するか否かを決定し、変更すると決定した場合、前記仮想マシンの実行に使用可能な前記ハードウェアリソースの量の変更を、前記サーバに指示する情報処理装置と、
    を有する情報処理システム。
JP2017168719A 2017-09-01 2017-09-01 情報処理装置、仮想マシン監視プログラム、および情報処理システム Active JP6940761B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017168719A JP6940761B2 (ja) 2017-09-01 2017-09-01 情報処理装置、仮想マシン監視プログラム、および情報処理システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017168719A JP6940761B2 (ja) 2017-09-01 2017-09-01 情報処理装置、仮想マシン監視プログラム、および情報処理システム

Publications (2)

Publication Number Publication Date
JP2019046163A true JP2019046163A (ja) 2019-03-22
JP6940761B2 JP6940761B2 (ja) 2021-09-29

Family

ID=65815740

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017168719A Active JP6940761B2 (ja) 2017-09-01 2017-09-01 情報処理装置、仮想マシン監視プログラム、および情報処理システム

Country Status (1)

Country Link
JP (1) JP6940761B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111522843A (zh) * 2020-06-01 2020-08-11 北京创鑫旅程网络技术有限公司 数据平台的控制方法、***、设备及存储介质
JP2021043893A (ja) * 2019-09-13 2021-03-18 株式会社日立製作所 リソースの利用効率の最適化を支援するシステム及び方法
JP2024016782A (ja) * 2022-07-26 2024-02-07 北京穿楊科技有限公司 リソース割り当ての決定方法、装置、計算装置及びコンピュータプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012198843A (ja) * 2011-03-23 2012-10-18 Fuji Xerox Co Ltd 仮想サーバ調整システム、仮想サーバ制御装置及びプログラム
JP2013257789A (ja) * 2012-06-13 2013-12-26 Fujitsu Marketing Ltd サーバ制御装置およびサーバ制御プログラム
JP2014164425A (ja) * 2013-02-22 2014-09-08 Sony Corp 情報処理装置、リソース制御方法及びプログラム
JP2016149058A (ja) * 2015-02-13 2016-08-18 株式会社日立システムズ リソース制御システムおよびリソース制御方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012198843A (ja) * 2011-03-23 2012-10-18 Fuji Xerox Co Ltd 仮想サーバ調整システム、仮想サーバ制御装置及びプログラム
JP2013257789A (ja) * 2012-06-13 2013-12-26 Fujitsu Marketing Ltd サーバ制御装置およびサーバ制御プログラム
JP2014164425A (ja) * 2013-02-22 2014-09-08 Sony Corp 情報処理装置、リソース制御方法及びプログラム
JP2016149058A (ja) * 2015-02-13 2016-08-18 株式会社日立システムズ リソース制御システムおよびリソース制御方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2021043893A (ja) * 2019-09-13 2021-03-18 株式会社日立製作所 リソースの利用効率の最適化を支援するシステム及び方法
JP7229888B2 (ja) 2019-09-13 2023-02-28 株式会社日立製作所 リソースの利用効率の最適化を支援するシステム及び方法
CN111522843A (zh) * 2020-06-01 2020-08-11 北京创鑫旅程网络技术有限公司 数据平台的控制方法、***、设备及存储介质
JP2024016782A (ja) * 2022-07-26 2024-02-07 北京穿楊科技有限公司 リソース割り当ての決定方法、装置、計算装置及びコンピュータプログラム

Also Published As

Publication number Publication date
JP6940761B2 (ja) 2021-09-29

Similar Documents

Publication Publication Date Title
US10225333B2 (en) Management method and apparatus
JP6277827B2 (ja) 情報処理装置、スケール管理方法およびプログラム
US9384031B2 (en) Information processor apparatus, virtual machine management method and virtual machine management program
JP6455035B2 (ja) 負荷分散管理装置、制御方法およびプログラム
JP7004902B2 (ja) 性能評価プログラム、および性能評価方法
JP5218390B2 (ja) 自律制御サーバ、仮想サーバの制御方法及びプログラム
JP6447329B2 (ja) 並列計算制御装置、並列計算システムおよびマイグレーション時間推定プログラム
US20120221730A1 (en) Resource control system and resource control method
JP7011162B2 (ja) 性能調整プログラム、および性能調整方法
US20140244844A1 (en) Control device and resource control method
JP6293683B2 (ja) 計算機システム及び計算機システムの性能障害の対処方法
JP6940761B2 (ja) 情報処理装置、仮想マシン監視プログラム、および情報処理システム
WO2024119763A1 (zh) 一种容器集群算力调度方法及相关装置
US10754368B1 (en) Method and system for load balancing backup resources
JP2004030292A (ja) コンピュータのシステム構成導出方法及び装置
KR20190042465A (ko) 분할 메모리 관리장치 및 방법
JP5515889B2 (ja) 仮想マシンシステム、自動マイグレーション方法および自動マイグレーションプログラム
JP2016099746A (ja) ストレージ管理装置、ストレージ管理方法及びストレージ管理プログラム
JP2012043098A (ja) 管理装置,ファイルサーバシステム,処理方法及び管理プログラム
JP6451308B2 (ja) ストレージ装置およびストレージ装置制御プログラム
KR20160139082A (ko) 역경매 방식 자원할당 장치를 포함하는 하이브리드 클라우드 서버 및 그 자원 할당 방법 및 시스템
JP6627475B2 (ja) 処理リソース制御プログラム、処理リソース制御装置、および処理リソース制御方法
EP3764229A1 (en) Information processing program, information processing method, and information processing apparatus
JP2018136681A (ja) 性能管理プログラム、性能管理方法、および管理装置
JP2022107464A (ja) 情報収集プログラム、情報収集方法および情報処理装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200611

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20200625

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20200625

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210202

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210402

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20210803

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210816

R150 Certificate of patent or registration of utility model

Ref document number: 6940761

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150