JP2016103179A - 計算機リソースの割り当て方法及び計算機システム - Google Patents
計算機リソースの割り当て方法及び計算機システム Download PDFInfo
- Publication number
- JP2016103179A JP2016103179A JP2014241535A JP2014241535A JP2016103179A JP 2016103179 A JP2016103179 A JP 2016103179A JP 2014241535 A JP2014241535 A JP 2014241535A JP 2014241535 A JP2014241535 A JP 2014241535A JP 2016103179 A JP2016103179 A JP 2016103179A
- Authority
- JP
- Japan
- Prior art keywords
- computer
- performance
- virtual
- service
- group
- 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.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3414—Workload generation, e.g. scripts, playback
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
- H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
- H04L43/0876—Network utilisation, e.g. volume of load or congestion level
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/50—Testing arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/815—Virtual
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computer Hardware Design (AREA)
- Computer Security & Cryptography (AREA)
- Environmental & Geological Engineering (AREA)
- Debugging And Monitoring (AREA)
Abstract
【課題】クラウド・システムにおいて、性能の低下を抑制して、適切な計算機リソースを提供する【解決手段】物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、1以上の仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機と、を備えた計算機システムであって、管理計算機は、前記サービスを提供する前記仮想計算機群の性能を取得して、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較し、当該比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する制御部と、前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する性能測定部と、を有し、前記制御部は、前記測定した性能が前記サービスの性能条件を満たす場合には前記変更を適用する。【選択図】図4
Description
本発明は、サービスに割り当てる計算機資源を動的に変更可能な計算機システムに関する。
近年のクラウド・コンピューティング技術の開発やクラウド・サービスの提供によって、サービスの利用者はハードウェアを管理する必要がなく、オペレーティング・システムやミドルウェアよりも上位のシステムのみを管理すればよいという環境が整いつつある。
クラウド・システムはAWS(Amazon Web Services)に代表されるようなパブリック・クラウドやプライベート・クラウド、あるいはそれらとオンプレミスのシステムを組み合わせたフェデレーテッド・クラウドがあり、構成方法は多岐にわたる。
多岐にわたるクラウド・システムの構成パターンの中から性能やコストに関して最適な構成を選択したいという要求が今後ますます大きくなると考えられる。さらにサービスはある程度需要予測が可能なものがある一方で、Webサービスなどでは需要予測が難しく、需要に対して動的にシステム性能を変更したいという要求は大きい。
特許文献1は、クラウド・システムにおけるクラウド・プロバイダ間あるいはクラウド基盤間の計算機資源(リソース)を共有する技術に関するものである。サービスがあるクラウド・システム上で稼働しており、当該クラウド・システムには余剰の計算機リソースがない場合、当該サービスが新たな計算機リソースを他のクラウド・プロバイダで獲得する技術が開示されている。
クラウド・システムでは複数のサービスが稼働していることが多い。あるいは、クラウド・システムでは複数のユーザが同じ計算機リソースを共有している場合がある。各クラウド・プロバイダが公表するカタログを参照することでユーザはクラウド・システムの性能を知ることができるが、クラウド・システムでは一般的に性能の保障はなく、いつ計算機リソースが獲得されたかによって実際の性能が大きく変わってしまうことがある。
これは、カタログ上は同じ性能でも実際には異なる物理リソースが割り当てられる場合がある。あるいは同じ計算機リソースを共有している他のプロセスがCPU、メモリ、ディスク、ネットワークなどを過剰に使用していることがあり、実際に割り当てられた計算機リソースでは、カタログのスペックよりも性能が低下することがある。これらはクラウド・システムにおいて、性能が保障されていない問題であることが広く認識されている。
そこで本発明は、上記問題点に鑑みてなされたもので、クラウド・システムにおいて、性能の低下を抑制して、適切な計算機リソースを提供することを目的とする。
本発明は、プロセッサとメモリを備えた物理計算機と、前記物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、1以上の前記仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機とを備えた計算機システムで、前記仮想計算機群を動的に変更する計算機リソースの割り当て方法であって、前記管理計算機が、前記サービスを提供する前記仮想計算機群の性能を取得する第1のステップと、前記管理計算機が、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較する第2のステップと、前記管理計算機が、前記比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する第3のステップと、前記管理計算機が、前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する第4のステップと、前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たすか否かを判定する第5のステップと、前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たす場合には、前記変更を適用する第6のステップと、を含む。
したがって、本発明は、コストや性能において最適な計算機リソースを提供しながらも、負荷の増減に対して動的に対応することができる。
以下、本発明の実施形態を添付図面に基づいて説明する。
本発明は、単一あるいは複数のクラウド・システム上に構築された業務システム(またはクライアントシステム)について、ユーザからのリクエストに応じて動的に割り当てる計算機リソースを拡大及び縮小する技術であり、そのための基盤である。このクラウド・システムを用いることで、サービスは単一あるいは複数のクラウド基盤(またはデータセンタ)の中からコストや性能に基づいて最適な計算機リソースを獲得しながら、リクエストの増減に対して動的に応じることができる。
図1Aは、本発明を適用したクラウド・システムの概略図を示すブロック図である。クラウド・システム100、1000は、複数の仮想計算機(VM)を含む計算機システムである。なお、クラウド・システム100、1000は本明細書に説明される構成や機能の範囲を限定するものではない。
クラウド・システム100は第1のデータセンタを構成し、クラウド・システム1000は第2のデータセンタを構成する。クラウド・システム100とクラウド・システム1000は地理的に異なる場所に配置され、あるいは、異なる建屋や、異なるフロアなどに配置することができる。
クラウド・システム100とクラウド・システム1000は、VPN(Virtual Private Network)90を介してクラウド基盤101とクラウド基盤1003が接続され、クラウド・システム100とクラウド・システム1000はひとつのネットワークとしてアクセス可能である。
クラウド・システム100は、外部のネットワーク80を介してエンドユーザ端末103に接続される。クラウド・システム100は、管理ネットワーク60を介してクラウド基盤管理者端末102とアプリ管理者端末116に接続される。
クラウド・システム100は、クラウド基盤101によって中心的な部分が構成されている。クラウド基盤101はクラウド基盤管理者端末102に管理されている。クラウド基盤101は、構成要素として管理サーバ104と、管理データ105と、リソースプール118と、ロードバランサ106と、データベース(図中DB)115を備える。
また、クラウド・システム100は、リソースプール118から割り当てられた仮想計算機(VM)セット117を備える。VMセット117は、アプリ管理者端末116が生成したウェブアプリケーション(図中WebApp)によるサービスを提供するWebAppサーバ112−1〜112−3を含む。なお、WebAppサーバの総称を添え字のない符号112で表す。また、他の構成要素についても同様であり、構成要素の総称を添え字のない符号で示す。
また、エンドユーザ端末103へサービスを提供する1以上の仮想計算機群(WebAppサーバ112−1〜112−3)を、運用中システムまたはクライアントシステムとする。
ロードバランサ106と、WebAppサーバ112とデータベース115は、業務ネットワーク70と管理ネットワーク60に接続される。管理サーバ104と、リソースプール118と、クラウド基盤管理者端末102と、アプリ管理者端末116は管理ネットワーク60のみに接続される。
これらのWebAppサーバ112はロードバランサ(図中LB)106を介してネットワーク80に接続される。エンドユーザ端末103から送信されたリクエストは、ネットワーク80を介してロードバランサ106で受信され、各WebAppサーバ112−1〜112−3に振り分けられる。
データベース115は、ウェブアプリケーションが使用するサービスのデータを格納し、WebAppサーバ112に接続される。
ロードバランサ106、WebAppサーバ112では性能測定とリソースの使用状況の取得のために監視エージェントが稼働している。各WebAppサーバ112及びロードバランサ106の監視エージェントのログは管理サーバ104に送られ、管理データ105に蓄積される。
管理サーバ104は、後述するように、WebAppサーバ112に割り当てる仮想計算機の拡大または縮小を行う前に、クライアントシステムを構成する仮想計算機の性能テストを実行する。そして、性能テストの結果、所定の性能条件を満足する仮想計算機を選択して、仮想計算機の追加または削減を動的に実施する。
ロードバランサ106は、性能測定を行うための機能として、上記性能テストが開始されるとエンドユーザ端末103からのリクエストをランダムにコピーして、性能テストの対象になるVMセットに振り分ける機能を備える。HTTPリクエストのコピーは、すべてランダムに選択する場合、ロードバランサ106がHTTPセッションを維持した上でランダムに選択する場合が考えられる。
さらに、ロードバランサ106はエンドユーザ端末103からのリクエストに対する平均応答時間を測定し、管理サーバ104に送信する機能を備える。ロードバランサ106は、また、エンドユーザ端末103からのリクエストを蓄積するために、管理サーバ104にコピーしたリクエストを送信する機能を備える。
データベース115では、性能テストを行う際に不整合がおきないようにする機能が必要である。データベース115では、スナップショットを使う。性能テストで発生した読み込みまたは書き込みアクセスを、データベース115のスナップショットで処理することで本番環境のデータに不整合が発生するのを防止する。
リソースプール118は、新たに仮想計算機(VM)を生成するためのCPU、メモリ、ディスクを含む計算機リソースである。リソースプール118は管理サーバ104に接続されており、VMの生成や削除などの命令は管理サーバ104から受け、ハイパバイザがVMの生成、削除を実施する。
クラウド・システム100に接続されたクラウド・システム1000は、リソースプール1010と、仮想計算機1112−1〜1112−2を含むVMセット109をクラウド基盤1003に含む。
図1Bは、本発明の第1の実施例を示し、クラウド基盤101の一例を示すブロック図である。クラウド基盤101は、管理ネットワーク60を介して物理計算機1と、ロードバランサ106と、管理サーバ104と、リソースプール118と、データベース115を格納するストレージ装置50が接続される。また、ロードバランサ106と、VMセット117を構成するVM#1(112−1)、VM#2(112−2)、VM#3(112−3)と、データベース115は業務ネットワーク70を介して接続される。
物理計算機1は、後述する図12に示す物理リソース10と、物理リソース10上で稼働するハイパバイザ(仮想化部)20と、ハイパバイザ20上で稼働する複数のVM#1〜VM#3からなるVMセット117とを含む。
VM#1〜VM#3では、それぞれ、性能及び計算機リソースを監視する監視エージェント22と、ウェブアプリケーション(図中WebApp)21が稼働する。このため、VM#1〜VM#3はWebAppサーバ112−1〜112−3として機能する。ウェブアプリケーション21は、HTTPサーバとアプリケーションサーバの機能を備え、データベース115を利用する。
リソースプール118も上記と同様であり、後述する図12に示す物理計算機と、物理計算機上で稼働するハイパバイザ(仮想化部)20と、ハイパバイザ20上で稼働する複数の仮想計算機を含む。
図示はしないが、クラウド・システム1000も同様であり、1以上の物理計算機と複数の仮想計算機が含まれ、管理サーバ104によって未割当の仮想計算機1112−1、1112−2がリソースプール1010に登録されている。
なお、ハイパバイザ20に代わって、VMM(Virtual Machine Monitor)を採用しても良い。
図12は、物理計算機1の構成の一例を示すブロック図である。物理計算機1は通信装置1402と、CPU1403と、メモリ1404と、表示装置1405と、入力装置1406と、記憶装置1407とを備え、管理ネットワーク60と、業務ネットワーク70に接続される。
本実施例では、管理サーバ104とロードバランサ106は図12と同様の物理計算機で構成する例を示すが、仮想計算機で構成してもよい。なお、クラウド・システム1000の仮想計算機1112−1、1112−2も図12と同様の物理計算機1上で稼働する。なお、CPU1403は、マルチコアプロセッサで構成することができる。
図2は、管理サーバ104の詳細を示すブロック図である。管理サーバ104は表示内容生成部203、制御プログラム208、管理データ105を備える。表示内容生成部203、制御プログラム208は、図12に示したメモリ1404にロードされて、CPU1403によって実行される。
管理サーバ104は、クラウド基盤管理者端末102およびアプリ管理者端末116が表示内容生成部203に接続されており、入出力の処理を行う。表示内容生成部203が出力する入力画面2140は、図13に示す。
制御プログラム208は全体統制部205と、ログ記憶部206と、DB管理部207と、性能測定部220とを備える。
全体統制部205は、アプリ管理者端末116が決定した入力を満たすように仮想計算機をリソースプール118から切り出す機能を備える。
ログ記憶部206は、各WebAppサーバ112やデータベース115やロードバランサ106などの管理サーバ104の管理下の装置で稼働する監視エージェント22から応答時間等の性能情報とVMのサイズなどのリソースの使用状況を収集し、管理データ105の運用中システムの性能ログ209に蓄積する。
また、ログ記憶部206は、エンドユーザ端末103からロードバランサ106に送られるリクエストを取得し、管理データ105のリクエストパターン215に格納する。あるいは、ロードバランサ106がリクエストの複製を管理サーバ104へ送信し、ログ記憶部206が取得してリクエストパターン215に蓄積することができる。なお、運用中システムの性能ログ209は、ロードバランサ106で稼働する監視エージェント22がWebAppサーバ112の応答時間等の性能情報を取得した性能情報である。ロードバランサ106は、性能情報を管理サーバ104へ送信し、管理サーバ104は、受信した性能情報を運用中システムの性能ログ209に蓄積する。なお、この性能情報は、運用中システム(クライアントシステム)の性能情報となる。
DB管理部207は、データベース115を管理する。特に本発明では後述する図3や図4に記述されるように仮想計算機の性能テストストを行うが、DB管理部207は性能テスト中に運用中のシステムに不整合が起こらないようにする機能を備える。
性能測定部220は、クラウド・システム100が拡大または縮小するときに生成される仮想計算機(VM)の性能テストを行う。本実施例では、管理サーバ104は、WebAppサーバ112に割り当てる仮想計算機の拡大または縮小を行う前に、テスト用の仮想計算機を生成し、性能測定部220が当該仮想計算機の性能テストを実行する。そして、管理サーバ104は、テスト用の仮想計算機のうちSLA情報を満足する仮想計算機を拡大または縮小の対象として選択する。なお、SLA情報は、後述するように、性能条件とコスト条件を含む運用情報である。
管理データ105は運用中のシステムの性能ログ209と、テストシステムの性能ログ210と、リソース一覧211と、SLA情報214と、リクエストパターン215と、VM性能情報216とを備える。
運用中システムの性能ログ209は、図5Aで示すように、秒間リクエスト数503と応答時間504を含む。秒間リクエスト数503は、ロードバランサ106が受け付けた単位時間当たりのリクエスト数を示す。応答時間504は、ロードバランサ106がエンドユーザ端末103からリクエストを受け付けてから応答するまでの時間を示す。なお、本実施例では、1つのサービスをWebAppサーバ112−1〜112−3で提供する例を示すが、複数のサービスを提供する場合には、サービス毎に運用中システムの性能ログ209を生成することができる。
テストシステムの性能ログ210は、図5Bで示すように、新しく生成されたVMの性能テストにおける秒間リクエスト数505と応答時間506を含む性能ログである。秒間リクエスト数505と応答時間506は、図5Aの運用中システムの性能ログ209と同様である。
リソース一覧211は、クラウド・システム100、1000ごとに利用可能なCPU、メモリ、ディスク、利用料金など計算機リソースの情報を含む。図9はデータセンタ毎のリソース一覧211を示す図である。
リソース一覧211は、クラウド・システム100またはクラウド基盤101の識別子(名称やIPアドレス)を格納するVM基盤901と、クラウド基盤101内のストレージの容量を格納するDisk902と、クラウド基盤101内の主記憶の容量を格納するメモリ903と、クラウド基盤101内のCPUのコア数を格納するCPU(コア数)904と、仮想計算機の使用料金を格納するVM価格(¥/h)905と、クラウド基盤101の稼働率を格納する可用性906をひとつのエントリに含む。
ここで、VM価格(¥/h)905には、クラウド・システム100が割り当てる計算機リソースのサイズに応じて、小規模の割り当て量である“S(Small)”と、Smallの2.5倍の計算機リソースを割り当てる“L(Large)”のそれぞれについて、単位時間当たりの仮想計算機の使用料金が格納される。なお、計算機リソースのサイズは、メモリ容量やストレージ容量やCPUコア数などで表すことができる。なお、VM基盤901には、リソースプールのIPアドレスを含んでもよい。
なお、上記では計算機リソースのサイズをSmallやLargeなどにより段階的に設定する例を示したが、CPU1403のコア数やメモリ容量などで示してもよい。
SLA(Service Level Agreement)情報214は、図7で示すように、エンドユーザが定めるコスト703と、要求応答時間704と、要件の優先順位705と、可用性706と、クラウド・プロバイダ707と、デプロイするアプリ708と、システム構成709とを含む。SLA情報214は、アプリ管理者端末116が予め設定する情報または条件である。
図7は、SLA情報214の一例を示す図である。SLA情報214は、要件701と内容702のフィールドをひとつのエントリに含む。
コスト703には、エンドユーザとクラウド・システム100のデータセンタが契約した時間当たりの利用料金の上限が設定される。要求応答時間704には、クラウド・システム100がリクエストを受け付けてから応答を送信するまでの許容時間を設定される。要件の優先順位705には、要件701のうち第1に優先すべき要件と、第2に優先すべき要件が設定される。可用性706には、エンドユーザとクラウド・システム100が契約した稼働率が設定される。クラウド・プロバイダ707には、利用可能な1以上のクラウド・プロバイダの名称が設定される。デプロイするアプリ708には、エンドユーザが使用するアプリケーションとアプリケーションの配置に関する情報が設定される。システム構成709には、エンドユーザが使用するシステムの内容が設定される。
なお、本実施例では、1つのエンドユーザがクラウド・システム100を利用する例を示すが、クラウド・システム100が複数のエンドユーザにサービスを提供する場合には、エンドユーザ毎にSLA情報214が設定される。
次に、リクエストパターン215は、エンドユーザ端末103が過去にクラウド・システム100へ送ったリクエストを蓄積した集合である。図10は、リクエストの一例を示す図である。図10は、一つのPOSTリクエスト1101の一例を示す。HTTPリクエストではGETリクエストも含まれる。
図11は、リクエストパターン215の一例を示す図である。リクエストパターン215は、番号1201と、リクエスト1202をひとつのエントリに含む。リクエスト1202には、アクセスのメソッドや、URLなどが含まる。
VM性能情報216は、運用中のクラウド・システム100のVMの性能情報であり、VMごとにサイズと応答時間を備える。
図8は、VM性能情報216の一例を示す図である。VM性能情報216は、VMの識別子及び場所を格納するVM ID801と、VMの規模を格納するVMサイズ802と、ロードバランサ106がリクエストを送信してからVMが応答を受信するまでの時間を格納する応答時間803とを含む。
VMサイズ802は、上記リソース一覧211と同様であり、Smallに割り当てる計算機リソースを1とすると、Largeに割り当てる計算機リソースは2.5倍となる。したがって、VMサイズ802=Small×2は、Smallの2倍の計算機リソース量となる。なお、VM性能情報216は、管理サーバ104が、ロードバランサ106から所定の周期などで取得し、更新する。
なお、管理サーバ104が実行する制御プログラム208は、大きく分けて、全体統制部205と、ログ記憶部206と、DB管理部207と、性能測定部220の4つの機能を有するが、それらの機能は独立したサーバで分散して実行されても良い。
図3は、管理サーバ104で行われる割り当て計算機リソースを増加する処理の一例を示すフローチャートである。
クラウド・システム100では、WebAppサーバ112−1〜112−3でエンドユーザ端末103に対して所定のサービスを提供している。エンドユーザ端末103はWebAppサーバ112で稼働しているサービスに対してリクエストを送信し、WebAppサーバ112は逐次処理して応答する。
応答時間などの性能情報と計算機リソースの使用状況は、ロードバランサ106やVM#1〜VM#3の監視エージェント22によって常に監視されている。アプリ管理者端末116は、予めSLA情報214を定めて管理サーバ104に送信し、管理サーバ104で保存されている。管理サーバ104は、所定の周期で各監視エージェント22からの性能情報と計算機リソースの使用状況を取得し、運用中システムの性能ログ209を更新する。
管理サーバ104の、全体統制部205は、ロードバランサ106等の監視エージェント22からの監視結果がSLA情報214を満たさないと判定すると、図3のフローチャートを開始して、監視対象のWebAppサーバ112にSLA情報214を満たす計算機リソースを追加する。なお、管理サーバ104が図3の処理を開始する契機としては、運用中システムの性能ログ209を監視してSLA情報214を維持できなくなったときの他、クラウド基盤管理者端末102からの指令を受信したときなど、所定の契機であればよい。
ステップ301では、管理サーバ104のDB管理部207が、データベース115の記憶領域のスナップショットを生成する。生成されたスナップショットは、例えば、ストレージ装置50に格納しておけば良い。
ステップ302では、管理サーバ104の全体統制部205が現在稼働しているクラウド基盤101で、計算機リソースに余剰があるかを判定する。この判定は、全体統制部205が、現在運用中のWebAppサーバ112に割り当てた計算機リソースと同等の計算機リソースをリソースプール118で確保可能であるかを基準として判定する。現在WebAppサーバ112が稼働しているクラウド基盤101で、十分な計算機リソースがリソースプール118で確保できない場合はステップ303に進む。
ステップ303では、全体統制部205が、リソース一覧211のうちからVMを生成するのに十分な計算機リソースをリソースプールで確保可能な他のクラウド基盤を選択する。このとき、全体統制部205が、図9に示されるデータセンタごとの利用可能な計算機リソースを示すリソース一覧211を参照する。このリソース一覧211は、全体統制部205が各クラウド・プロバイダや、データセンタに所定の周期でアクセスすることで情報を取得して更新する。
なお、全体統制部205が選択するクラウド基盤は、ひとつではなく、複数のクラウド基盤を選択して遅延や処理性能が異なる計算機リソースを確保して性能テスト用のVMを生成してもよい。
上記ステップ302、303で、テスト用のVMを生成するクラウド基盤で計算機リソースが確保されると、ステップ304に進む。
ステップ304では、全体統制部205及び性能測定部220が、上記ステップ302、303で確保された計算機リソースを割り当てたVMを複数生成して、性能テストを実行する。
ここで、管理サーバ104の全体統制部205は、図6に示す、インスタンス毎のテスト結果テーブル601を生成する。
ここでは簡単のためクラウド・プロバイダごとに定義されるインスタンス(VMインスタンス)のサイズがSmallとLargeのラベルは、同じ物理リソース量を指すものとする。さらにサイズLargeはSmallの計算機リソースの2.5倍とする。ただし、クラウド・プロバイダごとにインスタンス名や計算機リソースの性能値は異なる。なお、運用中のWebAppサーバ112のVMのサイズと応答時間の関係は、図8に示したVM性能情報216から取得する。
さらに、全体統制部205は、SLA情報214と運用中システムの性能ログ209を参照することで、クライアントシステムに追加する計算機リソースで処理すべきリクエストの量を推定することができる。
全体統制部205は、推定したリクエストの量から、サイズがSmallとLargeの計算機リソース(VM)をいくつ用意すれば良いかを推定することが可能である。すなわち、全体統制部205は、クライアントシステムに割り当てた計算機リソースについて、割り当てを変更する計算機リソースの量を決定する。
ただし、サイズがSmallとLargeの計算機リソース(VM)で、単位時間当たりに処理可能なリクエスト数は予め設定しておいてもよい。全体統制部205は、上記推測結果と各データセンタの情報を併せて、VMセットの一覧を性能テスト結果テーブル601として生成する。
図6は、インスタンス毎の性能テスト結果テーブル601の一例を示す図である。図6の性能テスト結果テーブル601は、運用中システム(クライアントシステム)にVMを追加するため、テストを実行したVMセットの一覧を示すものである。
性能テスト結果テーブル601は、インスタンスの種類を格納するインスタンス602と、当該インスタンスを提供するクラウド・システムの場所とクラウド・プロバイダを格納する場所(事業者)603と、性能テストの結果、当該インスタンスの応答時間(秒)を格納する応答時間604と、単位時間当たりの使用料金を格納する価格605と、利用可能なクラウド・システム全体の単位時間当たりの使用料金を格納するシステム全体の価格606とがひとつのエントリに含まれる。
次に、クラウド・システム100システムが、図8に示されるVM#1、VM#2、VM#3で構成され、図5Aに示した運用中システムの性能ログ209のようにリクエストを1秒間で300件程度受け付けているとする。
さらに、全体統制部205は、図9に示したデータセンタごとのリソース一覧211と、図7に示したSLA情報214を参照する。全体統制部205は、SLA情報214の行704を参照し、要求応答時間は6秒以内という定義を取得する。全体統制部205は、図5Aの運用中システムの性能ログ209を参照し、応答時間6秒とするには運用中システムで200件のリクエストを処理し、残りの100件のリクエストを他のシステム(計算機リソース)で処理する必要があることを判定することができる。
また、クラウド・システム100の構成が変更される前は、図8に示したようにVM#1、VM#2、VM#3のLarge=1台、Small=3台分で稼働しているので、全体統制部205は、外部の計算機リソースからSmall=2.25台分を確保する必要があると判定できる。すなわち、WebAppサーバ112は、Small相当で5.5台分の計算機リソースで200のリクエストを処理し、残りの100のリクエストをSmall相当で2.25台分の計算機リソースで処理することを示す。
全体統制部205が、Small=2.25台分の計算機リソースを確保する方法として、Small=1台、Small=×2台、Large=1台が価格の上限(図7のコスト703)から候補となりうる。
その結果、全体統制部205は、図7の行707から利用可能なクラウド・プロバイダを取得し、クラウド・プロバイダ毎に、Small=1台、Small=×2台、Large=1台のエントリを、図6に示した性能テスト結果テーブル601のインスタンス602、場所603に生成する。また。全体統制部205は、図6の価格605、システム全体の価格606には、図示しないカタログ情報の値を設定する。
ステップ304では、全体統制部205が生成した性能テスト結果テーブル601に基づいてテスト用のVMを生成して、性能テストを行う。全体統制部205がテスト用のVMを生成するとき、単一のVMセットあるいは複数のVMセットを生成して同時にテストを行う。性能測定部220は、テスト用のVMでクライアントシステムと同様のウェブアプリケーション21を実行し、サービスを試行させる。そして、サービスを試行中のテスト用のVMの性能を測定する。
本実施例では、図1に示すように、全体統制部205、異なるクラウド・プロバイダのクラウド・システム1000で、リソースプール1010からテスト用のVMセット109を生成する例を示す。また、全体統制部205、クラウド・システム100でも、リソースプール118からテスト用のVMセット405(図4参照)を生成する。
図1のクラウド・システム1000は、WebAppサーバにおけるスケールアウトを示しており、VMセット109、405(図示省略)がテストされる例である。1つのVMセット109であるVM1112−1、1112−2が、クラウド・システム100のロードバランサ106に登録される。
性能測定部220は、生成したVM1112−1、1112−2にウェブアプリケーション21を実行させる。ロードバランサ106は、WebAppサーバ112へのリクエストをコピーし、コピーしたリクエストをテスト用のVM1112へ送信する。テスト用のVM1112は、ロードバランサ106からのリクエストの複製を受信して、ウェブアプリケーション21が処理を実行し、クライアントシステムのサービスを試行する。性能測定部220は、サービスを試行している期間で、テスト用のVM1112の性能を測定する。性能の測定は、ロードバランサ106の監視エージェント22がテスト用のVMの応答時間を測定し、管理サーバ104へ送信する。
ステップ304では、テスト用のVMセット109、405の性能テストを並列で行う場合があるが、運用中システム(WebAppサーバ112)の性能に対して影響がないようにする必要がある。このため、性能テストを行うVMセットは性能測定部220によって開始時刻をずらすことで運用中システムの計算機リソースの稼働率が徐々に上昇する。
そして、全体統制部205は、配下の監視する監視エージェント22からの性能ログを取得して、運用中システムのハードウェア計算機リソースの稼働率と、クラウド・システム100の性能を常に監視することで運用中システムに影響を与えないようにする。
1つ以上のVMセット109、405を生成した場合、全体統制部205がステップ305でVMに対する性能テストの結果から、SLA情報214を満たす最適なVMセット109を選択する。
上記図6の性能テスト結果テーブル601を生成した時点では、応答時間604が未定であったが、上記性能テストを行うことで、性能測定部220が応答時間604に値を設定することができる。なお、図6において、A社のVMが図1のVMセット109に相当する。その他のVMセットは、クラウド・システム100の図示しないテスト用のVMとして生成されたものである(VMセット2)。
図6に示す性能テスト結果テーブル601では、図7のSLA情報214のコスト950円/時間以内、要求応答時間6秒以内を満たすものとしてVMセット(607)が選ばれる。なお、図6の行608は、運用中システム(WebAppサーバ112)の性能劣化を引き起こす可能性があったため、性能測定部220が性能測定をしなかった場合を示す。
ここで、性能測定部220は、性能テストを実施した各VMセット109、405について、図5Bに示したテストシステムの性能ログ210を生成する。図5Aの運用中システムの性能ログ209は、運用中のWebAppサーバ112に対して生成されたテーブルである。
また、ステップ306では、全体統制部205が選択したVM(1112)を運用中システムに組み込む。このとき、全体統制部205は、ロードバランサ106に追加されたVMについてリクエストの振り分け割合の設定を行う。すなわち、全体統制部205は、クラウド・システム100のWebAppサーバ112へリクエストの2/3を振り分け、クラウド・システム1000のWebAppサーバ1112へリクエストの1/3を振り分けるように、ロードバランサ106に指令する。これにより、全体統制部205は、選択したVMセットをクライアントシステムに追加して計算機リソースの変更を動的に適用する。
上記ステップ304で複数のテスト用のVMセットが生成された場合は、性能測定部220が、選択されたテスト用のVMセット以外を削除する。また、性能テストで用いられたデータベース115のスナップショットは全体統制部205が削除する。
図4は、上記ステップ304で行われる性能テストの一例を示すシーケンス図である。 管理サーバ104の全体統制部205からリソースプール118、1010にVMセットを生成する命令が出される。なお、VMセットの生成命令は、リソースプール118,1010の物理計算機上で稼働するハイパバイザ20に対して送信される。全体統制部205から命令を受けるリソースプールは1つあるいは複数である。本実施例では、クラウド・システム100のリソースプール118と、クラウド・システム100のリソースプール1010でテスト用のVMを生成する例を示す。
リソースプール118、1010のハイパバイザ20は一つあるいは複数のVMセットの生成命令をそれぞれ受け付け、テスト対象となるVMセット109、405を予め設定したVMイメージから生成する。
図4では2つのVMセット109、405が生成される場合を示しているが、2つのVMセットに限定されない。
図1において、運用中システムのVMセット117以外にテスト用のVMセット405と、クラウド・システム1000にはテスト用のVMセット109が生成され、クラウド基盤101とクラウド基盤1003が接続される。この例では、特にWebAppサーバにおけるスケールアウトを示しており、WebAppサーバの候補としてテスト用のVM1112−1、1112−2がロードバランサ106に追加される。なお、図4のVMセット405は、図1においては図示を省略した。
リソースプール118,1010のハイパバイザはVM生成命令を受け付けると、管理サーバ104の全体統制部205にVM生成の受け付け通知を送信する。その後、管理サーバ104の性能測定部220は、ロードバランサ106に対してVMセット109、405に負荷をかけるように命令する。このときロードバランサ106は運用中システムに対するリクエストをコピーして、リクエストの複製をVMセット109、405に送信する。
ロードバランサ106はVMセット109、405からの応答を受け付け、管理サーバ104の性能測定部220に応答時間などの測定結果を送る。管理サーバ104の全体統制部205は測定結果から上述のように最適なテスト対象のVMセット109を選択し、それ以外のテスト対象のVMセット405を削除するようにリソースプール118に通知する。そして、全体統制部205は、選択されたVMセット109を運用中システム(クライアントシステム)に追加する。
上記図4の性能テストにおいて、ロードバランサ106がリクエストのコピーをテスト用VMに送信して、運用中システムと並列的に性能テストを行う例を示したが、性能テストの入力データは、リクエストのコピーに限定されるものではない。
管理サーバ104の性能測定部220が、リクエストパターン215に蓄積された過去のリクエストをテスト用のVMセット109、405へ送信することで、性能テストを実施しても良い。
この場合、まず全体統制部205が性能測定部220に対して負荷かけ開始の命令を出力する。続いて性能測定部220がロードバランサ106にリクエストを送り、ロードバランサ106がVMセット109、405にリクエストを振り分ける。
この例では、ロードバランサ106はリクエストをコピーする機能を持つ必要はない。ロードバランサ106に複数のポートあるいはIPアドレスを設定し、第1のポートあるいは第1のIPアドレスで受けたリクエストは運用中のシステムに振り分け、第2のポートあるいは第2のIPアドレスで受けたリクエストは性能テストの対象VMセットに送られるように設定する。
上記ロードバランサ106で行うリクエストのコピーの機能はロードバランサ106とエンドユーザ端末103の間にスイッチを配置し、スイッチで代替することもできる。
図5Aは、運用中のシステムの性能ログの一例を示す図である。図5Bは、テスト対象のVMセットの性能ログの一例を示す図である。
管理サーバ104は、テスト対象のVMセット109を運用中システムに追加する際に、運用中システムと追加されるテスト対象VMセット109に対する負荷の割合を決定し、VMが追加された後にシステム全体として応答性能が確保できるかを推定する。
運用中システムの性能ログ209は、運用中システムに関する性能情報を記録したテーブルである。運用中システムの性能ログ209は運用中システムの性能であり、運用開始後に生成されるテーブルである。
運用中システムの性能ログ209の、秒間リクエスト数503には、エンドユーザ端末103からのリクエスト数あるいはシステムに対する負荷を表す値が格納される。応答時間504は平均応答時間あるいは性能に関する情報を表す。
テストシステムの性能ログ210はテスト対象のVMセットに関する性能のテーブルである。テストシステムの性能ログ210は、性能テストの開始後に生成されるテーブルである。秒間リクエスト数505は、秒間リクエスト数503と同様にリクエスト数あるいはシステムに対する負荷の量を表す値が格納される。応答時間506は応答時間504同様に応答時間あるいは性能に関する情報を表すカラムである。
図13は、SLA情報214の入力画面2140の一例を示す画面イメージである。この入力画面2140は、管理サーバ104がアプリ管理者端末116へ提供する。図示の入力画面2140のフォーマットは、図7に示したSLA情報214と同様である。
入力画面2140は、要件2141と内容2142のフィールドをひとつのエントリに含む。コスト2143には、時間当たりの利用料金の上限が設定される。要求応答時間2144には、クラウド・システム100がリクエストを受け付けてからWebApp21が応答を出力するまでの許容時間が設定される。要件の優先順位2145には、要件2141のうち第1に優先すべき要件と、第2に優先すべき要件が設定される。可用性2146には、エンドユーザとクラウド・システム100が契約した稼働率が設定される。クラウド・プロバイダ2147には、利用可能な1以上のクラウド・プロバイダの名称が設定される。デプロイするアプリ2148には、エンドユーザが使用するアプリケーションとアプリケーションの配置に関する情報が設定される。システム構成2149には、エンドユーザが使用するシステムの内容が設定される。
図14は、第1の実施例の変形例を示し、クラウド・システムの機能の一例を示すブロック図である。
図14では、管理サーバ104がデータベース115のレプリカ119を生成し、レプリカに対してスナップショットを生成する。そして、テスト用のVMセット109はレプリカ119のスナップショットを利用して性能テストを実行する。この場合、運用中システムへの影響は、レプリカ119を用いない場合に比して小さくなる。
以上の処理によって、管理サーバ104は、運用中システムの性能ログ209を参照して、SLA情報214を満足できないと判定すると、SLA情報214を満足する計算機リソース量を決定し、当該計算機リソース量に相当するVMを生成して性能テストを実施する。管理サーバ104は、性能テストによりSLA情報214を満足することができると判定すると、当該計算機リソースを現在運用中のクライアントシステムに追加する。
これにより、クラウド・システム100のカタログの性能ではなく、実際の性能に応じた計算機リソースをクライアントシステム(仮想計算機群)に割り当てることができる。
そして、クラウド・システム100において、クライアントシステムの性能を保証して前記従来例のような性能の低下を抑制し、適切な計算機リソースを提供することが可能となる。また、クライアントシステムに追加する計算機リソースは、管理サーバ104が自動的に最適な量の計算機リソース(VMのサイズまたは量)を演算し、演算結果に応じた計算機リソースを有するVMを生成する。そして、管理サーバ104は、生成したVMについて性能テストを実施して、性能テストの結果、SLA情報214を満たすVMを選択することでSLA情報214を保証することができる。これにより、クラウド・システム100でサービスを提供するクライアントシステムに割り当てる計算機リソースを効率よく制御することが可能となる。
そして、クラウド・システム100において、クライアントシステムの性能を保証して前記従来例のような性能の低下を抑制し、適切な計算機リソースを提供することが可能となる。また、クライアントシステムに追加する計算機リソースは、管理サーバ104が自動的に最適な量の計算機リソース(VMのサイズまたは量)を演算し、演算結果に応じた計算機リソースを有するVMを生成する。そして、管理サーバ104は、生成したVMについて性能テストを実施して、性能テストの結果、SLA情報214を満たすVMを選択することでSLA情報214を保証することができる。これにより、クラウド・システム100でサービスを提供するクライアントシステムに割り当てる計算機リソースを効率よく制御することが可能となる。
前記実施例1では、クラウド・システム100のクライアントシステムをスケールアウトさせ、計算機リソースを増加させる例を示した。本実施例2ではクラウド・システム100のクライアントシステムが過剰な計算機リソースを保有する場合に、計算機リソースを解放する例について説明する。なお、クラウド・システム100等の構成は前記実施例1と同様である。
管理サーバ104は運用中システムの性能ログ209を参照し、クライアントシステムの性能がアプリ管理者端末116が設定したSLA情報214を過剰に満たす場合、当該WebAppサーバ112に割り当てられているVMの負荷を徐々に解除してSLA情報214を満たしていれば当該VMを削除し、運用中システムを縮小する。SLA情報214を過剰に満たす場合は、例えば、要求応答時間704が6秒の場合に、応答時間の平均が3秒の場合などで、計算機リソースが過剰に割り当てられている場合である。
なお、クライアントシステムの性能が、SLA情報214を過剰に満たす場合とは、例えば、SLA情報214で設定した性能条件の2倍以上など、所定の閾値を超えた性能を有する場合である。
図8は、運用中のVMごとのVM性能情報216であり、図8において、VM ID801の場所がTokyoのVM#1〜VM#3が図1のWebAppサーバ112−1〜112−3に相当し、図中VM#4、VM#5がクラウド・システム1000の仮想計算機1112−1、1112−2に相当する。
全体統制部205は、応答時間803のうち応答時間が最も長いVM#5(1112−2)を選択する。次に、全体統制部205は、ロードバランサ106のリクエストを振り分ける機能の設定を変更し、VM#5へのリクエストを徐々に減らす。そして、全体統制部205は、VM#5へのリクエストの配信を完全に停止できるかを判定する。
なお、VM#5へのリクエストを徐々に減らす手法としては、ロードバランサ106が、所定の周期(例えば、5秒)ごとに所定数ずつリクエストを減じて、最終的にリクエスト数を0にしてVM#5の負荷を開示すれば良い。
この判定は、全体統制部205が、WebAppサーバとして機能しているVM#5(仮想計算機1112−2)へのリクエストを、他のVMで処理してもSLA情報214を満たすことができるか否かを判定する。
全体統制部205は、VM#5へのリクエストを徐々に減らす過程で、運用中システムの応答時間を監視し、SLA情報214を満足できない場合には、VMを削除する試みを停止する。
全体統制部205は、VM#5へのリクエストの配信を完全に停止するまでSLA情報214を満足する場合、クラウド基盤1003のハイパバイザに対してVM#5を削除する指令を送信する。
全体統制部205は、続いて、VM#4(WebAppサーバ112−1)に対しても上記と同様にVM#4の削除を試みる。全体統制部205はSLA情報214を満足できなくなると、VM#4の削除を中止して、現在運用中システムで最大限の性能が得られるリクエストの振り分けに戻す。
以上の処理によって、管理サーバ104は、運用中システム(クライアントシステム)の性能ログ209を参照して、SLA情報214を上回る性能を付与している場合には、応答時間の最も長い(最も性能の低い)VMを削除する。このとき、管理サーバ104は、削除対象のVMへ送信するリクエスト数を徐々に減らしながら運用中システム全体でSLA情報214を満足するかを監視する。管理サーバ104は、単位時間当たりのリクエスト数を所定数ずつ減じることで、リクエスト数を徐々に減らす。そして、管理サーバ104は、削除対象のVMへのリクエストを停止してもSLA情報214を満足していれば、当該VMを削除し、当該VMの計算機リソースをリソースプール118,1010に戻すことができる。
以上の処理により、運用中システムのSLA情報214を満足させながら計算機リソースの割り当て増大と、割り当ての削減を動的に行うことが出来る。
また、動的に変更する計算機リソースは、管理サーバ104が自動的に最適な量の計算機リソースを演算し、性能テストによってSLA情報214を保証する。これにより、クラウド・システム100の計算機リソースの割り当てを効率よく自動化することが可能となる。
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。
また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD(Solid State Drive)等の記録装置、または、ICカード、SDカード、DVD等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
1 物理計算機
20 ハイパバイザ
100 クラウド・システム
104 管理サーバ
105 管理データ
106 ロードバランサ
112−1〜112−3 WebAppサーバ
115 データベース
118 リソースプール
209 運用中システムの性能ログ
210 テストシステムの性能ログ
214 SLA情報
20 ハイパバイザ
100 クラウド・システム
104 管理サーバ
105 管理データ
106 ロードバランサ
112−1〜112−3 WebAppサーバ
115 データベース
118 リソースプール
209 運用中システムの性能ログ
210 テストシステムの性能ログ
214 SLA情報
Claims (15)
- プロセッサとメモリを備えた物理計算機と、前記物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、1以上の前記仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機とを備えた計算機システムで、前記仮想計算機群を動的に変更する計算機リソースの割り当て方法であって、
前記管理計算機が、前記サービスを提供する前記仮想計算機群の性能を取得する第1のステップと、
前記管理計算機が、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較する第2のステップと、
前記管理計算機が、前記比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する第3のステップと、
前記管理計算機が、前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する第4のステップと、
前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たすか否かを判定する第5のステップと、
前記管理計算機が、前記測定した性能が前記サービスの性能条件を満たす場合には、前記変更を適用する第6のステップと、
を含むことを特徴とする計算機リソースの割り当て方法。 - 請求項1に記載の計算機リソースの割り当て方法であって、
前記第3のステップは、
前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、
前記第4のステップは、
前記決定された計算機リソースに応じたテスト用の仮想計算機を生成するステップと、
前記テスト用の仮想計算機で前記サービスを試行させるステップと、
前記テスト用の仮想計算機の性能を測定するステップと、を含み、
前記第6のステップは、
前記測定したテスト用の仮想計算機の性能が前記サービスの性能条件を満たす場合には、前記テスト用の仮想計算機を前記仮想計算機群に追加することを特徴とする計算機リソースの割り当て方法。 - 請求項1に記載の計算機リソースの割り当て方法であって、
前記第3のステップは、
前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、
前記第4のステップは、
前記決定された計算機リソースに応じたテスト用の仮想計算機を複数生成するステップと、
複数の前記テスト用の仮想計算機で前記サービスをそれぞれ試行させるステップと、
前記テスト用の仮想計算機の性能をそれぞれ測定するステップと、を含み、
前記第6のステップは、
前記複数のテスト用の仮想計算機のうち前記測定した性能が前記サービスの性能条件を満たすテスト用の仮想計算機を選択し、前記仮想計算機群に追加することを特徴とする計算機リソースの割り当て方法。 - 請求項3に記載の計算機リソースの割り当て方法であって、
前記第4のステップは、
前記決定された計算機リソースに応じたテスト用の仮想計算機を当該計算機システムと、他の計算機システムでそれぞれ生成することを特徴とする計算機リソースの割り当て方法。 - 請求項1に記載の計算機リソースの割り当て方法であって、
前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサを含み、
前記第4のステップは、
前記管理計算機が前記ロードバランサに指令して、前記リクエストの複製を前記変更の対象となる計算機リソースに応じた仮想計算機に送信させ、当該リクエストに応じた処理を実行させることを特徴とする計算機リソースの割り当て方法。 - 請求項1に記載の計算機リソースの割り当て方法であって、
前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサを含み、
前記第4のステップは、
前記管理計算機が前記ロードバランサから前記リクエストを取得して蓄積し、前記蓄積したリクエストを、変更の対象となる計算機リソースに応じた仮想計算機に送信し、当該リクエストに応じた処理を実行させることを特徴とする計算機リソースの割り当て方法。 - 請求項1に記載の計算機リソースの割り当て方法であって、
前記計算機システムは、前記サービスで使用するデータベースを含み、
前記第4のステップは、
前記データベースのスナップショットを生成するステップと、
前記変更の対象となる計算機リソースに応じた仮想計算機で前記スナップショットを用いて前記サービスを試行して、当該仮想計算機の性能を測定するステップと、を含むことを特徴とする計算機リソースの割り当て方法。 - 請求項1に記載の計算機リソースの割り当て方法であって、
前記計算機システムは、前記サービスで使用するデータベースと、当該データベースのレプリカとを含み、
前記第4のステップは、
前記レプリカのスナップショットを生成するステップと、
前記変更の対象となる計算機リソースに応じた仮想計算機で前記スナップショットを用いて前記サービスを試行して、当該仮想計算機の性能を測定するステップと、を含むことを特徴とする計算機リソースの割り当て方法。 - 請求項1に記載の計算機リソースの割り当て方法であって、
前記第3のステップは、
前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件よりも所定の閾値を超えたきには、前記仮想計算機群から削除する計算機リソースを決定し、
前記第4のステップは、
前記決定された計算機リソースに応じた仮想計算機の負荷を漸次解除して前記サービスを試行させるステップと、
前記仮想計算機群の性能を測定するステップと、を含み、
前記第6のステップは、
前記仮想計算機群の性能が前記サービスの性能条件を満たす場合には、前記仮想計算機を前記仮想計算機群から削除することを特徴とする計算機リソースの割り当て方法。 - プロセッサとメモリを備えた物理計算機と、
前記物理計算機の計算機リソースを仮想計算機に割り当てる仮想化部と、
1以上の前記仮想計算機でサービスを提供する仮想計算機群を制御する管理計算機と、を備えた計算機システムであって、
前記管理計算機は、
前記サービスを提供する前記仮想計算機群の性能を取得して、前記取得した前記仮想計算機群の性能と、予め設定された前記サービスの性能条件とを比較し、当該比較結果に応じて、前記仮想計算機群で変更する計算機リソースを決定する制御部と、
前記変更の対象となる計算機リソースに応じた仮想計算機で前記サービスを試行して、当該仮想計算機の性能を測定する性能測定部と、を有し、
前記制御部は、
前記測定した性能が前記サービスの性能条件を満たす場合には、前記変更を適用することを特徴とする計算機システム。 - 請求項10に記載の計算機システムであって、
前記制御部は、
前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、前記決定された計算機リソースに応じたテスト用の仮想計算機を生成し、
前記性能測定部は、
前記テスト用の仮想計算機で前記サービスを試行させて、前記テスト用の仮想計算機の性能を測定し、
さらに、前記制御部は、
前記測定したテスト用の仮想計算機の性能が前記サービスの性能条件を満たす場合には、前記テスト用の仮想計算機を前記仮想計算機群に追加することを特徴とする計算機システム。 - 請求項10に記載の計算機システムであって、
前記制御部は、
前記比較結果が、前記仮想計算機群の性能が前記サービスの性能条件を満たしていないときには、前記仮想計算機群に追加する計算機リソースを決定し、前記決定された計算機リソースに応じたテスト用の仮想計算機を複数生成し、
前記性能測定部は、
複数の前記テスト用の仮想計算機で前記サービスをそれぞれ試行させて、前記テスト用の仮想計算機の性能をそれぞれ測定し、
さらに、前記制御部は、
前記複数のテスト用の仮想計算機のうち前記測定した性能が前記サービスの性能条件を満たすテスト用の仮想計算機を選択し、前記仮想計算機群に追加することを特徴とする計算機システム。 - 請求項12に記載の計算機システムであって、
前記制御部は、
前記決定された計算機リソースに応じたテスト用の仮想計算機を当該計算機システムと、他の計算機システムでそれぞれ生成することを特徴とする計算機システム。 - 請求項10に記載の計算機システムであって、
前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサをさらに含み、
前記制御部は、
前記ロードバランサに指令して、前記リクエストの複製を前記変更の対象となる計算機リソースに応じた仮想計算機に送信させ、当該リクエストに応じた処理を実行させることを特徴とする計算機システム。 - 請求項10に記載の計算機システムであって、
前記計算機システムは、前記仮想計算機群へリクエストを配信するロードバランサをさらに含み、
前記制御部は、
前記ロードバランサから前記リクエストを取得して蓄積し、前記蓄積したリクエストを、変更の対象となる計算機リソースに応じた仮想計算機に送信し、当該リクエストに応じた処理を実行させることを特徴とする計算機システム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014241535A JP2016103179A (ja) | 2014-11-28 | 2014-11-28 | 計算機リソースの割り当て方法及び計算機システム |
US14/635,538 US20160156567A1 (en) | 2014-11-28 | 2015-03-02 | Allocation method of a computer resource and computer system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014241535A JP2016103179A (ja) | 2014-11-28 | 2014-11-28 | 計算機リソースの割り当て方法及び計算機システム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2016103179A true JP2016103179A (ja) | 2016-06-02 |
Family
ID=56079908
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014241535A Pending JP2016103179A (ja) | 2014-11-28 | 2014-11-28 | 計算機リソースの割り当て方法及び計算機システム |
Country Status (2)
Country | Link |
---|---|
US (1) | US20160156567A1 (ja) |
JP (1) | JP2016103179A (ja) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018020603A1 (ja) * | 2016-07-27 | 2018-02-01 | 株式会社日立製作所 | 計算機システム及びアクセラレータ管理方法 |
JP2018195113A (ja) * | 2017-05-18 | 2018-12-06 | 株式会社デンソーテン | 管理サーバ、クラウドシステム、及び管理方法 |
WO2019187209A1 (ja) * | 2018-03-30 | 2019-10-03 | 日本電気株式会社 | 運用管理装置、方法及び非一時的なコンピュータ可読媒体 |
DE112017006981T5 (de) | 2017-03-03 | 2019-10-24 | Mitsubishi Electric Corporation | Verarbeitungsaufteilungsvorrichtung, simulatorsystem, verarbeitungsaufteilungsverfahren und verarbeitungsaufteilungsprogramm |
CN117453424A (zh) * | 2023-12-26 | 2024-01-26 | 北京航空航天大学杭州创新研究院 | 可动态扩展计算资源的加速算法运行效率的方法及装置 |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20160344657A1 (en) * | 2015-05-20 | 2016-11-24 | International Business Machines Corporation | PROVIDING PERFORMANCE ALTERNATIVES BASED ON COMPARATIVE PRICE AND PERFORMANCE DATA OF A RUNNING SaaS INSTANCE |
WO2017099732A1 (en) * | 2015-12-08 | 2017-06-15 | Hewlett Packard Enterprise Development Lp | Cloud-based testing |
US10554751B2 (en) * | 2016-01-27 | 2020-02-04 | Oracle International Corporation | Initial resource provisioning in cloud systems |
US10296363B2 (en) * | 2016-09-16 | 2019-05-21 | Oracle International Corporation | Tuning a virtual machine startup parameter |
US9800514B1 (en) | 2016-12-15 | 2017-10-24 | Red Hat, Inc. | Prioritizing data packets in a network |
US10581745B2 (en) * | 2017-12-11 | 2020-03-03 | International Business Machines Corporation | Dynamic throttling thresholds |
JP7013934B2 (ja) * | 2018-02-26 | 2022-02-01 | オムロン株式会社 | コントローラ |
US10977072B2 (en) | 2019-04-25 | 2021-04-13 | At&T Intellectual Property I, L.P. | Dedicated distribution of computing resources in virtualized environments |
US11539635B2 (en) | 2021-05-10 | 2022-12-27 | Oracle International Corporation | Using constraint programming to set resource allocation limitations for allocating resources to consumers |
US11502971B1 (en) * | 2021-11-15 | 2022-11-15 | Oracle International Corporation | Using multi-phase constraint programming to assign resource guarantees of consumers to hosts |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7577722B1 (en) * | 2002-04-05 | 2009-08-18 | Vmware, Inc. | Provisioning of computer systems using virtual machines |
US8307177B2 (en) * | 2008-09-05 | 2012-11-06 | Commvault Systems, Inc. | Systems and methods for management of virtualization data |
US8732427B2 (en) * | 2009-08-03 | 2014-05-20 | Quantum Corporation | Systems and methods for collapsing a derivative version of a primary storage volume |
US20110078303A1 (en) * | 2009-09-30 | 2011-03-31 | Alcatel-Lucent Usa Inc. | Dynamic load balancing and scaling of allocated cloud resources in an enterprise network |
US20120173709A1 (en) * | 2011-01-05 | 2012-07-05 | Li Li | Seamless scaling of enterprise applications |
US9250944B2 (en) * | 2011-08-30 | 2016-02-02 | International Business Machines Corporation | Selection of virtual machines from pools of pre-provisioned virtual machines in a networked computing environment |
US9038063B2 (en) * | 2011-09-07 | 2015-05-19 | International Business Machines Corporation | Determining virtual machine image pattern distributions in a networked computing environment |
US8930948B2 (en) * | 2012-06-21 | 2015-01-06 | Vmware, Inc. | Opportunistically proactive resource management using spare capacity |
WO2014014479A1 (en) * | 2012-07-20 | 2014-01-23 | Hewlett-Packard Development Company, L.P. | Policy-based scaling of network resources |
US10713183B2 (en) * | 2012-11-28 | 2020-07-14 | Red Hat Israel, Ltd. | Virtual machine backup using snapshots and current configuration |
US9304793B2 (en) * | 2013-01-16 | 2016-04-05 | Vce Company, Llc | Master automation service |
US9524215B1 (en) * | 2013-07-30 | 2016-12-20 | Veritas Technologies Llc | Systems and methods for managing virtual machine backups |
US9207976B2 (en) * | 2013-08-13 | 2015-12-08 | International Business Machines Corporation | Management of prioritizing virtual machines in an operating environment |
US9246840B2 (en) * | 2013-12-13 | 2016-01-26 | International Business Machines Corporation | Dynamically move heterogeneous cloud resources based on workload analysis |
US9424065B2 (en) * | 2014-06-26 | 2016-08-23 | Vmware, Inc. | Methods and apparatus to scale application deployments in cloud computing environments using virtual machine pools |
US9619266B2 (en) * | 2014-10-10 | 2017-04-11 | International Business Machines Corporation | Tearing down virtual machines implementing parallel operators in a streaming application based on performance |
-
2014
- 2014-11-28 JP JP2014241535A patent/JP2016103179A/ja active Pending
-
2015
- 2015-03-02 US US14/635,538 patent/US20160156567A1/en not_active Abandoned
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018020603A1 (ja) * | 2016-07-27 | 2018-02-01 | 株式会社日立製作所 | 計算機システム及びアクセラレータ管理方法 |
DE112017006981T5 (de) | 2017-03-03 | 2019-10-24 | Mitsubishi Electric Corporation | Verarbeitungsaufteilungsvorrichtung, simulatorsystem, verarbeitungsaufteilungsverfahren und verarbeitungsaufteilungsprogramm |
JP2018195113A (ja) * | 2017-05-18 | 2018-12-06 | 株式会社デンソーテン | 管理サーバ、クラウドシステム、及び管理方法 |
WO2019187209A1 (ja) * | 2018-03-30 | 2019-10-03 | 日本電気株式会社 | 運用管理装置、方法及び非一時的なコンピュータ可読媒体 |
JPWO2019187209A1 (ja) * | 2018-03-30 | 2021-02-12 | 日本電気株式会社 | 運用管理装置、方法及びプログラム |
JP7060083B2 (ja) | 2018-03-30 | 2022-04-26 | 日本電気株式会社 | 運用管理装置、方法及びプログラム |
CN117453424A (zh) * | 2023-12-26 | 2024-01-26 | 北京航空航天大学杭州创新研究院 | 可动态扩展计算资源的加速算法运行效率的方法及装置 |
CN117453424B (zh) * | 2023-12-26 | 2024-04-19 | 北京航空航天大学杭州创新研究院 | 可动态扩展计算资源的加速算法运行效率的方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
US20160156567A1 (en) | 2016-06-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2016103179A (ja) | 計算機リソースの割り当て方法及び計算機システム | |
US11182196B2 (en) | Unified resource management for containers and virtual machines | |
US10798016B2 (en) | Policy-based scaling of network resources | |
US9760395B2 (en) | Monitoring hypervisor and provisioned instances of hosted virtual machines using monitoring templates | |
US10291476B1 (en) | Method and apparatus for automatically deploying applications in a multi-cloud networking system | |
US9588789B2 (en) | Management apparatus and workload distribution management method | |
US8863138B2 (en) | Application service performance in cloud computing | |
CN107534570B (zh) | 用于虚拟化网络功能监控的计算机***、方法和介质 | |
KR101977726B1 (ko) | 가상 데스크탑 서비스 방법 및 장치 | |
US10394475B2 (en) | Method and system for memory allocation in a disaggregated memory architecture | |
JP4240062B2 (ja) | 計算機システムおよび性能計測方法ならびに管理サーバ装置 | |
US9466036B1 (en) | Automated reconfiguration of shared network resources | |
US8104038B1 (en) | Matching descriptions of resources with workload requirements | |
US20130019015A1 (en) | Application Resource Manager over a Cloud | |
US20100274890A1 (en) | Methods and apparatus to get feedback information in virtual environment for server load balancing | |
US10764158B2 (en) | Dynamic system level agreement provisioning | |
US20170017511A1 (en) | Method for memory management in virtual machines, and corresponding system and computer program product | |
US20150263960A1 (en) | Method and apparatus for cloud bursting and cloud balancing of instances across clouds | |
US20150264117A1 (en) | Processes for a highly scalable, distributed, multi-cloud application deployment, orchestration and delivery fabric | |
US11263037B2 (en) | Virtual machine deployment | |
US11966768B2 (en) | Apparatus and method for multi-cloud service platform | |
US20200110631A1 (en) | Virtual machine deployment method and omm virtual machine | |
US20140359127A1 (en) | Zero touch deployment of private cloud infrastructure | |
US20150263980A1 (en) | Method and apparatus for rapid instance deployment on a cloud using a multi-cloud controller | |
US20210373968A1 (en) | Load leveling device, load leveling method, and load leveling program |