JP2012133630A - ストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法 - Google Patents

Abstract

【課題】各テナントの仮想ＤＢサーバによるストレージリソースの使用量について「最低保証型」の性能保証を容易に行うことができるストレージリソース制御システムを提供する。
【解決手段】帯域制御部２２１によって仮想ＤＢサーバ２３１’によるネットワークの帯域の使用量を制御することによってストレージサーバ２４０のリソースの使用可能量を制御するためのストレージリソース制御システム１００’であって、仮想ＤＢサーバ２３１’は、ストレージサーバ２４０上のＲＥＤＯログ２１１−２、ＡＲＣＨログ２１１−３、およびＤＢデータ２１１−１に対してそれぞれ異なるネットワークパスによりアクセス可能なように仮想ネットワーク２１２’が構成されており、ＤＢ測定情報１１１’および仮想ＤＢサーバ２３１’の構成情報に基づいて帯域制御部２２１に対して設定するネットワークパス毎の帯域使用量の上限値を決定して出力する帯域決定部１３０’を有する。
【選択図】図６

Description

本発明は、マルチテナント形態のコンピュータシステムにおける各テナントのリソース使用量の制御技術に関し、特に、ストレージ機器のリソース使用量について最低保証型の性能保証を行うよう制御するためのストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法に適用して有効な技術に関するものである。

近年、企業等においては、ＩＴコスト削減のために、クラウドコンピューティング環境の利用などによってコンピュータリソースを他の企業や他の部門、プロジェクト等との間で共有する形態（マルチテナント形態）が注目されている。特に、エンタープライズ用途でマルチテナント形態が採用される場合、データセンター等においてコンピュータリソースを運用・管理するＩＴベンダーとしては、各テナントに対する「性能保証」が重要な課題となる。

一般的に、「性能保証」を行うための制御方法は、「優先制御型」と「最低保証型」の２つに大きく分類される。「優先制御型」は、いわゆるベストエフォート型の保証形態であり、各テナントに対して使用可能なリソース量の目安は設定されるものの、例えば、他のテナントでの処理も含めて、コンピュータリソースが不足する状況となった場合、優先度の低いテナントに割り当てられたリソースは優先度の高い処理を行うテナントに優先的に割り当てられ侵食される。一方、「最低保障型」では、各テナントは少なくとも使用可能として割り当てられた範囲でのリソースの使用は保証される（他のテナントでの処理によって侵食されない）。

物理サーバのリソース（ＣＰＵ（Central Processing Unit）やメモリ等）を、各テナントのアプリケーションが稼働する複数の仮想サーバによって共有するための手段としては、例えばＶＭｗａｒｅ（登録商標）などを始めとして様々な仮想化ソフトウェア製品が存在し、性能保証を行うための制御手段も十分揃っている。一方で、ストレージ機器（特にミッドレンジ以下）のリソースの共有に関しては、「優先制御型」の性能保証機能を有する製品は存在するものの、一般的に「最低保証型」の性能保証機能を有するものはほとんど存在せず、実現のためには何らかの仕組みを実装する必要がある。

これに関する技術として、例えば特開２０１０−１２２８１４号公報（特許文献１）には、アプリケーションに割り当てられる論理ボリュームを提供するディスクアレイグループを備えたストレージ装置について、ストレージ管理部は、アレイグループのスループット、レスポンスタイムと、記憶容量とを保持しており、論理ボリュームについて要求される、スループットと記憶容量との比である性能密度と、記憶容量の要件とを受け付け、前記アレイグループから前記スループットの値を上限として、受け付けた前記性能密度と容量要件に基づいて前記スループットを論理ボリュームに割り当て、割り当てたスループットと、受け付けた前記容量要件とに基づいて決定した記憶容量を、前記論理ボリュームに割り当てることで、ストレージ資源を性能面、容量面でバランスよく効率的に記憶領域として割り当てるストレージシステムが記載されている。

特開２０１０−１２２８１４号公報

上述したように、ストレージ機器のリソース共有において「最低保証型」の性能保証機能を実現するためには、何らかの仕組みを実装する必要がある。しかしながら、特許文献１に記載したような技術では、要求されるリソースを論理ボリュームに割り当てて、その範囲内で制御する仕組みは提供されるものの、特に、ストレージがデータベース（ＤＢ）サーバにおいて利用されるような場合は考慮されていない。ＤＢサーバのようなアプリケーションの場合、ＤＢサーバからのストレージに対する入出力特性（ストレージに対するアクセスパターン）が複数混在することになるため、アプリケーション（ＤＢサーバ）に対してストレージリソースの使用量を適切に割り当てて制御することは困難である。

そこで本発明の目的は、各テナントのストレージ機器のリソース使用量について「最低保証型」の性能保証を容易に行うことができるストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法を提供することにある。特に、ＤＢサーバによるストレージリソースの使用量についても「最低保証型」の性能保証を行うことができるストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態によるストレージリソース制御システムは、ネットワークを介してストレージサーバが接続された１つ以上の物理サーバ上において、前記ネットワークに対する帯域制御機能を有する仮想化ソフトウェアにより、テナント毎に仮想化された複数の仮想データベースサーバが前記物理サーバおよび前記ストレージサーバのリソースを共有する形態で稼働するリソースプールに対して、前記帯域制御機能によって前記仮想データベースサーバによる前記ネットワークの帯域の使用量を制御することによって、前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御するためのストレージリソース制御システムであって、以下の特徴を有するものである。

すなわち、前記仮想データベースサーバは、前記ストレージサーバ上に有する、前記仮想データベースサーバによる作業履歴ログを保持する作業履歴ログボリューム、過去の作業履歴ログをアーカイブするアーカイブログボリューム、およびその他のデータを保持するＤＢデータボリュームに対して、それぞれ異なるネットワークパスによりアクセス可能なように仮想ネットワークが構成されている。

また、該ストレージリソース制御システムは、前記ネットワークおよび前記ストレージサーバについてのパフォーマンスに係る測定情報、および前記仮想データベースサーバの構成情報に基づいて、前記仮想化ソフトウェアの前記帯域制御機能に対して設定する、前記ストレージサーバ上の各ボリュームにアクセスするための前記仮想ネットワークにおけるネットワークパス毎の帯域使用量の上限値を決定して出力する帯域決定部を有することを特徴とする。

また、本発明は、コンピュータを上記のようなストレージリソース制御システムとして機能させるプログラムにも適用することができる。また、本発明は、ネットワークを介してストレージサーバが接続された１つ以上の物理サーバ上において、仮想化ソフトウェアによりテナント毎に仮想化された複数の仮想データベースサーバが前記物理サーバおよび前記ストレージサーバのリソースを共有する形態で稼働するリソースプールに対して、前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御するストレージリソース制御方法にも適用することができる。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明の代表的な実施の形態によれば、各テナントのストレージ機器のリソース使用量について「最低保証型」の性能保証を容易に行うことが可能となる。特に、ＤＢサーバによるストレージのリソース使用量についても「最低保証型」の性能保証を行うことが可能となることで、他のテナントでの処理により受ける影響を低減するとともに、データベース処理におけるスループットの向上および安定化を図ることが可能となる。

本発明の実施の形態１であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。 本発明の実施の形態１におけるモデル作成部によって作成される線形モデルのうちの入出力処理量モデルの例を示した図である。 本発明の実施の形態１における帯域制御情報を出力する処理の流れの例について概要を示したフローチャートである。 本発明の実施の形態１における割当情報を出力する処理の流れの例について概要を示したフローチャートである。 本発明の実施の形態２における物理サーバ上に仮想ＤＢサーバを構築する際の構成例について概要を示した図である。 本発明の実施の形態２であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。 本発明の実施の形態２における帯域制御情報を出力する処理の流れの例について概要を示したフローチャートである。 物理サーバ上に仮想ＤＢサーバを構築する際の一般的な構成例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜実施の形態１＞
本発明の実施の形態１であるストレージリソース制御システムを有する情報処理システムでは、ストレージ機器が接続された物理サーバ上に各テナント用の複数の仮想サーバを構築してマルチテナント形態として運用されるコンピュータシステムに対して、各仮想サーバによるストレージリソースの使用可能量を、仮想化ソフトウェア製品が通常有するネットワーク帯域制御機能を用いることで容易に制御する。すなわち、各仮想サーバについて、物理サーバとストレージ機器との間のネットワークの帯域の使用量に対してネットワーク帯域制御機能によってキャップを設定することで、間接的に各仮想サーバによるストレージリソースの使用可能量を制御する。

各仮想サーバによるストレージリソースの使用可能量をそれぞれ所定の範囲内に制御することにより、各仮想サーバが他の仮想サーバに使用可能量として割り当てられたストレージリソースまで侵食して使用すること抑止することができ、「最低保証型」の性能保証機能を実現することができる。なお、本実施の形態において、制御の対象となるストレージリソースとはストレージ機器における単位時間当たりのリソースの使用量（例えば、ストレージ機器のＣＰＵ使用率や、ディスクビジー率など）を指し、使用するディスク容量は含まないものとする。

ここで、仮想化ソフトウェア製品のネットワーク帯域制御機能を用いて間接的にストレージリソースの使用可能量を所定の範囲内に制御するという場合、少なくとも、物理サーバとストレージ機器との間のネットワーク帯域の使用量と、ストレージリソースの使用量との相関関係を把握しておく必要がある。そこで、本実施の形態では、ネットワーク帯域の使用量とストレージリソースの使用量との相関関係についてモデル（帯域使用量モデル）を作成し、当該モデルに基づいてストレージリソースの使用量の上限（使用可能量）に対応するネットワーク帯域の使用量の上限を決定する。

本実施の形態では、各仮想サーバに対して、ストレージリソースの使用量の上限（使用可能量）を割り当てることになるが、これは、各仮想サーバ上で稼働するアプリケーションがその入出力処理のためにどれだけのストレージリソースを必要とするかによって定まる。ここで、各アプリケーションが必要とするストレージリソースの使用量を判断するためには、少なくとも、ストレージにおける入出力処理量とストレージリソースの使用量との相関関係を把握しておく必要がある。そこで、本実施の形態では、ストレージにおける入出力処理量とストレージリソースの使用量との相関関係についてもモデル（入出力処理量モデル）を作成し、当該モデルに基づいて、各仮想サーバで実行されるアプリケーションの入出力特性（入出力処理量）に応じて必要とされるストレージリソースの使用量を予測する。

上記の入出力処理量モデルと帯域使用量モデルを利用することで、各仮想サーバがアプリケーションでの入出力処理のために必要とするストレージリソースの使用量（最大使用量）に対応したネットワーク帯域の使用量を予測することができる。予測されたネットワーク帯域の使用量の情報を、帯域制御情報として仮想化ソフトウェアのネットワーク帯域制御機能に適用することで、各仮想サーバに割り当てられるストレージリソースの使用可能量を、アプリケーションの入出力特性から得られる最大使用量に応じて最適な値に設定することが可能となる。

［システム構成］
図１は、本実施の形態であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。図１において、情報処理システム１は、例えばＩＴベンダー等が、データセンター等の施設において、クラウドコンピューティング環境として多数のサーバ機器等からなるコンピュータリソースをリソースプール２００として運用・管理し、そのコンピュータリソースを他の企業や他の部門、プロジェクト等のユーザ（テナント）に対して、テナント間で共有する形態（マルチテナント形態）によりサービスとして提供するものである。

本実施の形態の情報処理システム１は、さらに、リソースプール２００によって提供されるストレージリソースについて、各テナントに対して「最低保証型」の性能保証機能を提供するため、各仮想サーバによるストレージリソースの使用量を所定の範囲内に制御するための情報を出力する機能を有するストレージリソース制御システム１００を有する。

情報処理システム１において、リソースプール２００は、複数の物理サーバ２１０（図１の例では、物理サーバＡ（２１０ａ）および物理サーバＢ（２１０ｂ））やストレージ２１１（図１の例ではストレージＡ（２１１ａ）およびストレージＢ（２１１ｂ））によって各テナントに対して提供される管理対象としてのコンピュータリソースの全体を総称するものである。各物理サーバ２１０は、それぞれ、仮想化ソフトウェア２２０（図１の例では仮想化ソフトウェアＡ（２２０ａ）および仮想化ソフトウェアＢ（２２０ｂ））によって仮想化され、その上でテナント毎に複数の仮想サーバ２３１（図１の例では、テナントａ１用仮想サーバ２３１ａ１、テナントａ２用仮想サーバ２３１ａ２およびテナントｂ１用仮想サーバ２３１ｂ１）が稼働している。

仮想化ソフトウェア２２０としては、ベンダー等から提供されている一般的なソフトウェア（例えば、ＶＭｗａｒｅやＸｅｎ（登録商標）など）を利用することができる。また、仮想サーバ２３１上で稼働するゲストＯＳ（Operating System）の種類なども特に限定されない。上記のような一般的な仮想化ソフトウェア２２０は、通常、各仮想サーバ２３１が使用するネットワークの帯域が、設定された（割り当てられた）上限値を超えないように制御するネットワーク帯域制御機能を有している。本実施の形態では、この機能は仮想化ソフトウェア２２０における帯域制御部２２１（図１の例では、帯域制御部Ａ（２２１ａ）および帯域制御部Ｂ（２２１ｂ））により提供されるものとする。

各物理サーバ２１０には、それぞれ、機器の内部もしくは外部のネットワーク２１２（図１の例ではネットワークＡ（２１２ａ）およびネットワークＢ（２１２ｂ））を介してストレージ２１１（図１の例ではストレージＡ（２１１ａ）およびストレージＢ（２１１ｂ））が接続されている。

以上のような構成により、各テナントの仮想サーバ２３１は、それぞれ、物理サーバ２１０やストレージ２１１のコンピュータリソース（本実施の形態では特に、ＣＰＵ使用率やディスクビジー率など単位時間あたりの使用率を割り当てることによって他のテナントと共有する形態となるもの）を、仮想化ソフトウェア２２０を介して共有する。

なお、本実施の形態では、ストレージ２１１は、特に「最低保証型」の性能保証機能を有さないミッドレンジ以下のストレージ機器を対象とする。これらのストレージ２１１は、例えば、物理サーバ２１０にローカル接続されたストレージ機器や、ｉＳＣＳＩ（Internet Small Computer System Interface）等を利用して構成されたＳＡＮ（Storage Area Network）、ＮＦＳ（Network File System）等を利用して構成されたＮＡＳ（Network Attached Storage）など、ストレージ２１１自身がＣＰＵを有してデータの読み書きを行うものであり、上記の仮想化ソフトウェア２２０の帯域制御部２２１によるネットワーク帯域制御機能により、物理サーバ２１０とストレージ２１１との間のネットワーク２１２の帯域制御が可能な構成とすることができるものであれば特に限定されない。

一方、ストレージリソース制御システム１００は、例えば、サーバやＰＣ（Personal Computer）などのコンピュータシステムにより構成され、ソフトウェアプログラムとして実装されるモデル作成部１１０、リソース予測部１２０、帯域決定部１３０および割当判定部１４０の各部を有する。これら各部は、それぞれが独立したプログラムとして実装されてもよいし、複数の部がまとまって１つのプログラムとして実装されてもよい。ストレージリソース制御システム１００は、リソースプール２００内の各物理サーバ２１０と図示しないネットワークを介して接続可能であってもよいし、オフラインで実装されていてもよい。また、独立したシステムとしてではなく他の運用管理システム等の一部として組み込まれて実装されてもよい。

本実施の形態では、上述したように、ストレージリソース制御システム１００によって、各仮想サーバ２３１がアプリケーションでの入出力処理のために必要とするストレージリソースの使用量に対応したネットワーク２１２の帯域の使用可能量を予測し、これを帯域制御情報として出力する。これを仮想化ソフトウェア２２０の帯域制御部２２１に適用することで、間接的に各仮想サーバ２３１のストレージリソースの使用可能量を制御し、「最低保証型」の性能保証機能を実現することができる。

ストレージリソース制御システム１００のモデル作成部１１０は、各仮想サーバ２３１によるネットワーク２１２の帯域の使用可能量を予測するために用いる、上述した入出力処理量モデルと帯域使用量モデルを作成する。詳細については後述するが、ここでは例えば、図示しない運用管理システム等を利用して測定もしくは収集し取得される、リソースプール２００内の各物理サーバ２１０のネットワーク２１２およびストレージ２１１についてのリソースの使用状況に係る情報であるリソース使用状況１１１を入力とし、ストレージ２１１における入出力処理量とストレージリソースの使用量についてのモデルである入出力処理量モデルと、ネットワーク２１２の帯域使用量とストレージリソースの使用量についてのモデルである帯域使用量モデルからなる線形モデル１１２を作成して出力する。

リソース予測部１２０は、上記の線形モデル１１２に基づいて、各テナントの仮想サーバ２３１がアプリケーションでの入出力処理のために必要とするストレージ２１１のリソース使用量に対応したネットワーク２１２の帯域使用量を予測する。ここでは、各仮想サーバ２３１上で稼働するアプリケーションについて予め分析されている入出力（Ｉ／Ｏ）の特性についての情報であるＩ／Ｏ特性１２１を入力として、線形モデル１１２のうちの入出力処理量モデルに基づいて、各仮想サーバ２３１（もしくはアプリケーション）が必要とするストレージ２１１のリソース使用量を予測する。さらに、線形モデル１１２のうちの帯域使用量モデルに基づいて、必要とするストレージ２１１のリソース使用量に対応するネットワーク２１２の帯域使用量を予測し、予測使用量１２２として出力する。

帯域決定部１３０は、予め定義された、帯域制御値の設定に係るポリシーの情報である設定ポリシー１３１に基づいて、上記の予測使用量１２２から、各仮想化ソフトウェア２２０の帯域制御部２２１に設定する、各仮想サーバ２３１についての帯域制御値を決定し、帯域制御情報１３２として出力する。この帯域制御情報１３２の内容を、ストレージリソース制御システム１００による自動もしくは管理者等による手動によって各仮想化ソフトウェア２２０の帯域制御部２２１に適用し、帯域制御部２２１により各仮想サーバ２３１によるネットワーク２１２の帯域使用量を制御する。これにより、間接的に各仮想サーバ２３１によるストレージ２１１のリソース使用量を所定の範囲内に制御することができる。

割当判定部１４０は、特定の新規または既存の仮想サーバ２３１について、どの物理サーバ２１０上に構築することができるか（どのストレージ２１１に対して割り当てることができるか）を判定する。例えば、新規に構築する予定の仮想サーバＣ（図示しない）についてリソース予測部１２０により得られた予測使用量１２２の情報と、各物理サーバ２１０のストレージ２１１の現状でのリソース使用状況１１１の情報とに基づいて、ストレージＡ（２１１ａ）、ストレージＢ（２１１ｂ）のいずれに割り当てることができるかを判定し、判定結果を割当情報１４２として出力する。

また例えば、既存の仮想サーバ（例えばテナントａ２用仮想サーバ２３１ａ２）においてアプリケーションでの処理内容や処理量を拡張したいというような場合、拡張するアプリケーションにおいて増加する入出力処理量に対応するストレージ２１１のリソース使用量をリソース予測部１２０によって予測して予測使用量１２２の情報を得る。

この予測使用量１２２の情報と、各物理サーバ２１０のストレージ２１１の現状でのリソース使用状況１１１の情報とに基づいて、テナントａ２用仮想サーバ２３１ａ２が現在のストレージＡ（２１１ａ）を利用したまま拡張することが可能なのか、物理サーバＢ（２１０ｂ）のストレージＢ（２１１ｂ）など他のストレージ２１１に移行して割り当てた上で拡張する必要があるのかなどを判定し、判定結果を割当情報１４２として出力する。

出力された割当情報１４２に基づいて、仮想サーバ２３１を対象の物理サーバ２１０（ストレージ２１１）に割り当てて構築もしくは拡張する。さらに、当該仮想サーバ２３１に対する帯域制御情報１３２を作成して、対象の仮想化ソフトウェア２２０の帯域制御部２２１に適用することで、「最低保証型」の性能保証機能を維持することができる。

［線形モデル（入出力処理量モデル、帯域使用量モデル）］
以下では、図１のストレージリソース制御システム１００のモデル作成部１１０が作成する線形モデル１１２について説明する。線形モデル１１２のうち、例えば入出力処理量モデルの作成に際しては、まずモデル作成部１１０は、図示しない運用管理システム等により測定・収集されたリソース使用状況１１１の情報から、ストレージ２１１のリソース使用量と、ストレージ２１１における入出力処理量を取得し、これらをストレージ２１１に対するアクセス種別毎に集計する。

ここで、ストレージ２１１のリソースとしては、上述したように、ＣＰＵ使用率やディスクビジー率など、単位時間（秒）あたりの使用率で表されるリソースが挙げられる。また、ストレージ２１１における入出力処理量としては、例えば、単位時間（秒）あたりの入出力処理数（ＩＯＰＳ（Input Output Per Second））を使用することができる。このＩＯＰＳの値は、例えば、ネットワーク２１２上のパケットを解析することにより間接的に取得することができる。ストレージ２１１に対するアクセス種別としては、例えば、同期／非同期のシーケンシャルライト、同期／非同期のランダムライト、シーケンシャルリード、ランダムリードなどが挙げられる。

図２は、図１においてモデル作成部１１０によって作成される線形モデル１１２のうちの入出力処理量モデルの例を示した図である。ここでは、アクセス種別のうち同期シーケンシャルライトを例として、ＣＰＵ使用率およびディスクビジー率とＩＯＰＳとの関係をそれぞれプロットしたものを示している。モデル作成部１１０は、これらのデータに基づいてＣＰＵ使用率およびディスクビジー率についてそれぞれ線形近似して入出力処理量モデルを作成する。線形近似の手法は特に限定されず、例えば最小二乗法などを用いることができる。

線形モデル１１２のうちの帯域使用量モデルの作成についても上記と同様であり、モデル作成部１１０は、図示しない運用管理システム等により測定・収集されたリソース使用状況１１１の情報から、ネットワーク２１２の帯域使用量とストレージ２１１のリソース使用量を取得し、これらをストレージ２１１に対するアクセス種別毎に集計する。ネットワーク２１２の帯域使用量としては、単位時間（秒）あたりの伝送データ量（ｂｐｓ）を使用することができる。これらのデータについて、図２の例と同様に、アクセス種別毎にＣＰＵ使用率およびディスクビジー率と帯域使用量との関係をそれぞれプロットし、最小二乗法等により線形近似して帯域使用量モデルを作成する。

上記のような線形モデル１１２を利用することで、入出力処理量モデルから、仮想サーバ２３１上で稼働するアプリケーションの入出力処理量に対して必要となるストレージ２１１のリソース使用量を予測することができ、さらに、帯域使用量モデルから、予測されたストレージ２１１のリソース使用量に対応するネットワーク２１２の帯域使用量を予測することが可能となる。

［処理フロー］
以下では、ストレージリソース制御システム１００による処理の流れについて説明する。図３は、各仮想化ソフトウェア２２０の帯域制御部２２１に適用するための帯域制御情報１３２を出力する処理の流れの例について概要を示したフローチャートである。当該処理を行う前の事前準備として、各ストレージ２１１についての上述した線形モデル１１２の作成は行われているものとする。

処理を開始すると、まず、帯域制御情報１３２により制御する対象となる仮想サーバ２３１上で稼働するアプリケーションのストレージ２１１に対する入出力特性を分析し、Ｉ／Ｏ特性１２１を取得してストレージリソース制御システム１００に入力する（Ｓ０１）。ここでは、Ｉ／Ｏ特性１２１として例えば、アプリケーションの処理内容から想定もしくは実測される、ストレージ２１１に対するアクセス種別毎の入出力処理量（ＩＯＰＳ）を取得する。例えば、
・同期ランダムライト →１，０００ＩＯＰＳ
・ランダムリード →２，０００ＩＯＰＳ
・その他のアクセス種別→なし
などの情報を得る。当該分析は、ストレージリソース制御システム１００の外部で管理者等が行ってもよいし、分析用のソフトウェアプログラムを実装してもよい。

次に、リソース予測部１２０は、Ｉ／Ｏ特性１２１を入力として、モデル作成部１１０により予め作成されている線形モデル１１２のうちの入出力処理量モデルを利用して、アプリケーションの入出力特性に対して必要となるストレージ２１１のリソース使用量を予測する（Ｓ０２）。例えば、図２に示したような線形近似された入出力処理量モデルから、
・ＣＰＵ使用率
・同期ランダムライト（１，０００ＩＯＰＳ）→１０％
・ランダムリード（２，０００ＩＯＰＳ） →１５％
・ディスクビジー率
・同期ランダムライト（１，０００ＩＯＰＳ）→５％
・ランダムリード（２，０００ＩＯＰＳ） →１０％
というような予測値を得る。

次に、リソース予測部１２０は、ステップＳ０２で得たリソース使用量の予測値に対して、線形モデル１１２のうちの帯域使用量モデルを利用して、必要となるストレージ２１１のリソース使用量に対して必要となるネットワーク２１２の帯域使用量を予測する（Ｓ０３）。例えば、図２に示したものと同様に線形近似された帯域使用量モデルから、
・ＣＰＵ使用率から予測したネットワーク２１２の帯域使用量
・同期ランダムライト（１０％）→１００Ｍｂｐｓ
・ランダムリード（１５％） →３００Ｍｂｐｓ
・ディスクビジー率から予測したネットワーク２１２の帯域使用量
・同期ランダムライト（５％） →５０Ｍｂｐｓ
・ランダムリード（１０％） →２００Ｍｂｐｓ
というような予測値を得る。

最後に、帯域決定部１３０は、ステップＳ０３で得たネットワーク２１２の帯域使用量の予測値から、設定ポリシー１３１に基づいて、帯域制御部２２１に適用する帯域上限値を決定し、帯域制御情報１３２として出力する（Ｓ０４）。例えば、設定ポリシー１３１として、「各ストレージリソース（ＣＰＵ使用率、ディスクビジー率）毎のネットワーク２１２の帯域使用量の予測値において最大値を上限値とする」というように設定されているものとすると、
・帯域上限値
・アウトバウンド（ライト）→１００Ｍｂｐｓ
・インバウンド（リード） →３００Ｍｂｐｓ
といような値を得る。

これらの値を対象の仮想サーバ２３１に対する帯域制御情報１３２として出力し、仮想化ソフトウェア２２０の帯域制御部２２１に適用することで、対象の仮想サーバ２３１のストレージ２１１のリソース使用量の上限を間接的に制御し、他の仮想サーバ２３１が必要とするリソース使用量を侵食しないようにする。これにより、ストレージ２１１全体として、各テナント（仮想サーバ２３１）間で「最低保証型」の性能保証機能を実現することができる。

なお、例えば、事前準備での線形モデル１１２の作成も含めた上記の一連の処理を定期的に自動で実行することで、リソースプール２００の各ストレージ２１１において、負荷状況に合わせて各仮想サーバ２３１のリソース使用量を動的に最適化して割り当てることも可能となる。

図４は、本実施の形態の線形モデル１１２（入出力処理量モデル）を利用することで、アプリケーションの入出力処理量から仮想サーバ２３１が必要とするストレージ２１１のリソース使用量を把握することが可能となることを利用した例として、特定の仮想サーバ２３１をいずれの物理サーバ２１０（ストレージ２１１）に割り当てるかを判定して割当情報１４２を出力する処理の流れの例について概要を示したフローチャートである。

この処理では、例えば、新規に仮想サーバ２３１を構築する際に、複数の物理サーバ２１０（ストレージ２１１）のうちいずれに割り当てるかの判定や、既存の仮想サーバ２３１の処理内容や処理量を拡張するような場合に、現状割り当てられている物理サーバ２１０（ストレージ２１１）上で可能なのか、他のストレージ２１１に移行した上で拡張する必要があるのかなどの判定を行うための情報を得ることができる。

当該処理を行う前の事前準備として、図３に示した例と同様に、各ストレージ２１１についての上述した線形モデル１１２の作成は行われているものとする。また、各ストレージ２１１の現在のリソースの使用状況がリソース使用状況１１１として得られているものとする。例えば、
・ストレージＡ（２１１ａ）
・ＣＰＵ使用率 →８０％
・ディスクビジー率→６０％
・ストレージＢ（２１１ｂ）
・ＣＰＵ使用率 →２０％
・ディスクビジー率→２０％
というような値が現在のリソース使用状況１１１として得られているものとする。

処理を開始すると、まず、対象となる仮想サーバ２３１上で稼働するアプリケーションのストレージ２１１に対する入出力特性を分析し、増加分のＩ／Ｏ特性１２１を取得してストレージリソース制御システム１００に入力する（Ｓ１１）。Ｉ／Ｏ特性１２１については、図３に示した例と同様であるが、新規の仮想サーバ２３１を構築する場合は、当該仮想サーバ２３１上で稼働する新たなアプリケーションの処理内容から想定される、ストレージ２１１に対するアクセス種別毎の入出力処理量を取得する。また、既存の仮想サーバ２３１を拡張する場合は、拡張により増加する分の入出力処理量を取得する。例えば、
・同期ランダムライト →１，０００ＩＯＰＳ増加
・ランダムリード →２，０００ＩＯＰＳ増加
・その他のアクセス種別→なし
などの情報を得る。

次に、リソース予測部１２０は、図３に示した例と同様に、Ｉ／Ｏ特性１２１を入力として、モデル作成部１１０により予め作成されている線形モデル１１２のうちの入出力処理量モデルを利用して、アプリケーションの入出力特性（増加分）に対して必要となるストレージ２１１のリソース使用量を予測する（Ｓ１２）。例えば、図２に示したような線形近似された入出力処理量モデルから、
・ＣＰＵ使用率
・同期ランダムライト（１，０００ＩＯＰＳ増加）→１０％増加
・ランダムリード（２，０００ＩＯＰＳ増加） →１５％増加
・ディスクビジー率
・同期ランダムライト（１，０００ＩＯＰＳ増加）→５％増加
・ランダムリード（２，０００ＩＯＰＳ増加） →１０％増加
というような予測値を得る。

次に、割当判定部１４０は、ステップＳ１２で得られたストレージ２１１のリソース使用量の予測値と、リソース使用状況１１１から得られる現在の各物理サーバ２１０のストレージ２１１のリソースの使用状況とから、対象の仮想サーバ２３１の割当先とする物理サーバ２１０（ストレージ２１１）、もしくは現状の物理サーバ２１０（ストレージ２１１）上での拡張可否を判定し、割当情報１４２として出力する（Ｓ１３）。例えば、新規に仮想サーバ２３１を構築する場合、
・ストレージＡ（２１１ａ）に割り当てた場合のリソース使用量
・ＣＰＵ使用率 →１０５％
・ディスクビジー率→７５％
・ストレージＢ（２１１ｂ）に割り当てた場合のリソース使用量
・ＣＰＵ使用率 →４５％
・ディスクビジー率→３５％
となり、ストレージＡ（２１１ａ）に割り当てた場合にはＣＰＵ使用率が１００％を超えてしまうため、まだリソースに余裕があるストレージＢ（２１１ｂ）に割り当てるのが適していると判定する。割り当て可能なストレージ２１１が複数ある場合は、予め定めたルール（例えば、ストレージ２１１の番号順や、空きリソース量の多い順など）に基づいて割り当てるようにしてもよい。

既存の仮想サーバ２３１を拡張する場合も同様に、例えばストレージＡ（２１１ａ）に割り当てられた仮想サーバＡ（２３１ａ）を対象とする場合、仮想サーバＡ（２３１ａ）上でアプリケーションを拡張すると、上記と同様にストレージＡ（２１１ａ）のＣＰＵ使用率が１００％を超えてしまうため、ここでの拡張は行えない。従って、リソースに余裕があるストレージＢ（２１１ｂ）に仮想サーバＡ（２３１ａ）を移行した後で拡張を行うか、もしくは、リソースに余裕があるストレージ２１１がない場合には拡張を見送るなどの判定を行う。

最後に、ステップＳ１３で得られた割当情報１４２に基づいて、自動もしくは管理者等による手動により、新規の仮想サーバ２３１のストレージ２１１への割当や、既存の仮想サーバ２３１の拡張などを行う（Ｓ１４）。以上の処理により、各テナントの仮想サーバ２３１上で稼働するアプリケーションの入出力特性に応じて仮想サーバ２３１の配置を最適化することが可能となる。

以上に示したように、本発明の実施の形態１であるストレージリソース制御システム１００によれば、各仮想サーバ２３１によるストレージ２１１のリソースの使用可能量を、仮想化ソフトウェア２２０が通常有するネットワーク帯域制御機能（帯域制御部２２１）を用いることで容易に制御する。すなわち、各仮想サーバ２３１について、物理サーバ２１０とストレージ２１１との間のネットワーク２１２の帯域使用量に帯域制御部２２１によってキャップを設定することで、間接的に各仮想サーバ２３１によるストレージ２１１のリソースの使用可能量を所定の範囲に制御し、他の仮想サーバ２３１に使用可能量として割り当てられているストレージリソースを侵食しないようにする。これにより、「最低保証型」の性能保証機能を実現することが可能となる。

また、モデル作成部１１０によって作成される入出力処理量モデルと帯域使用量モデルを利用することで、各仮想サーバ２３１がアプリケーションでの入出力処理のために必要とするストレージ２１１のリソース使用量に対応したネットワーク２１２の帯域使用量を予測することができる。予測された帯域使用量の情報を、帯域制御情報１３２として仮想化ソフトウェア２２０の帯域制御部２２１に適用することで、各仮想サーバ２３１に割り当てられるストレージリソースの使用可能量を、アプリケーションの入出力特性に応じて最適な値に設定することが可能となる。

＜実施の形態２＞
以下では、本発明の実施の形態２であるストレージリソース制御システムを有する情報処理システムについて説明する。

［概要］
上述した実施の形態１におけるストレージリソース制御システム１００によれば、各仮想サーバ２３１によるストレージ２１１のリソースの使用可能量を、仮想化ソフトウェア２２０のネットワーク帯域制御機能（帯域制御部２２１）を用いることで容易に制御し、「最低保証型」の性能保証機能を実現することができる。また、このとき、線形モデル１１２（入出力処理量モデルと帯域使用量モデル）を作成してこれを利用することで、各仮想サーバ２３１がアプリケーションでの入出力処理のために必要とするストレージ２１１のリソース使用量（最大使用量）に対応したネットワーク２１２の帯域使用量を予測することができる。

しかしながら、上記の線形モデル１１２を利用した帯域使用量の予測は、ストレージ２１１に対する入出力特性（ストレージに対するアクセスパターン）が混在していないアプリケーションを対象としている。仮想サーバ上で稼働するアプリケーションが例えばデータベース管理システム（ＤＢＭＳ（DataBase Management System））である場合、すなわち、仮想サーバが仮想ＤＢサーバである場合は、仮想ＤＢサーバからのストレージに対するアクセスパターンが複数混在することになるため、上記のような線形モデル１１２を利用してアプリケーション（仮想ＤＢサーバ）に対してストレージリソースの使用量を適切に割り当てて制御することは困難である。

図８は、物理サーバ上に仮想ＤＢサーバを構築する際の一般的な構成例について概要を示した図である。例えば、Ｏｒａｃｌｅ（登録商標）などを始めとする一般的なＤＢＭＳでは、データベースに対する各処理内容を記録してロールフォワードリカバリーを可能とするための作業履歴ログであるＲＥＤＯログ２１１−２、過去のＲＥＤＯログ２１１−２をアーカイブしておくためのアーカイブ（ＡＲＣＨ）ログ２１１−３、その他の実データ等（ＤＢデータ２１１−１）を、ストレージサーバ２４０上などでそれぞれ異なる論理ボリュームを構成して保持するのが一般的である。

また、これらのボリュームに対しては、例えばｉＳＣＳＩなどを利用したネットワーク上で、仮想ＤＢサーバ２３１’から１本の（仮想）ネットワークパスを構成してアクセスする。図８の例では、Ｌｉｎｕｘ（登録商標）上でＯｒａｃｌｅ ＶＭを利用して、ストレージサーバ２４０との間の仮想ネットワーク２１２’を利用する仮想ＤＢサーバを構成した場合の例を示している。

仮想ＤＢサーバ２３１’からのストレージサーバ２４０上の各ボリュームに対するアクセス特性はそれぞれ異なる場合がある。例えば、仮想ＤＢサーバ２３１’を利用してＤＢデータ２１１−１にアクセスするアプリケーションによる通常処理（ＯＬＴＰ（On-Line Transaction Processing：オンライントランザクション処理））の実行時や、バッチ処理、大量のデータ読み込みを伴うＤＳＳ（Decision Support System：意思決定支援システム）処理などの負荷の大きな処理の実行時、さらには仮想ＤＢサーバ２３１’によるＲＥＤＯログ２１１−２のログスイッチ時などで多くのストレージリソースを必要とするボリュームや、使用するリソースの分布状況は異なってくる。

これにより、例えば、バッチ処理やログスイッチなど、一時的に負荷の大きな処理が実行される場合、これらの処理がストレージリソースを大量に使用するため、通常処理（ＯＬＴＰ）やこれに伴うＲＥＤＯログ２１１−２への書き込み処理などが影響を受けてスループットが低下してしまう場合などが生じる。この状況は、本実施の形態のようなマルチテナント環境ではテナント間での処理が重複する場合があることにより一層顕著となる。

そこで、本実施の形態であるストレージリソース制御システムを有する情報処理システムでは、上記のようなアクセスパターンが異なる３種類のボリュームに対して、各テナントの仮想ＤＢサーバ２３１’からそれぞれ独立したネットワークパスを介してアクセスするように仮想ネットワークを構成する。

図５は、本実施の形態における物理サーバ上に仮想ＤＢサーバを構築する際の構成例について概要を示した図である。図５の例では、上述したように、仮想ＤＢサーバ２３１’がストレージサーバ２４０上の各ボリュームに対して、ＶＬＡＮ（Virtual LAN）などの仮想ネットワーク２１２’によって分離された異なるセグメントのネットワークパスを介してアクセスするように構成されている。なお、仮想ネットワークによる独立したネットワークパスの構成手段は特に限定されず、対象のプラットフォームなどに応じて公知の仮想ネットワーク技術を適宜利用することができる。

この仮想ネットワーク２１２’における各仮想ネットワークインタフェース（図５における仮想ＤＢサーバ２３１’上のｖｉｆ１．０〜１．２）に対して、実施の形態１と同様に、仮想化ソフトウェア２２０のネットワーク帯域制御機能を利用してアクセス先のボリュームの特性に合わせた帯域使用量の制御を行う。これにより、仮想ＤＢサーバ２３１’によるストレージサーバ２４０のリソース使用量についても「最低保証型」の性能保証を行うことを可能とし、他のテナントでの処理により受ける影響を低減する。また、各ボリュームに対するアクセスの特性に応じてストレージリソースを効率的に配分することで、データベース処理におけるスループットの向上および安定化を図ることを可能とする。

［システム構成］
図６は、本実施の形態であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。図６において、情報処理システム１のリソースプール２００における各物理サーバ２１０およびストレージサーバ２４０は、上述した図５と同様の構成を有する。すなわち、仮想ＤＢサーバ２３１’がストレージサーバ２４０上の各ボリュームに対して、仮想ネットワーク２１２’によって構成された異なるセグメントのネットワークパスを介してアクセスするように構成されている。この仮想ネットワーク２１２’に対して、仮想化ソフトウェア２２０の帯域制御部２２１よるネットワーク帯域制御機能を利用してアクセス先のボリュームの特性に合わせた帯域使用量の制御を行う。

一方、ストレージリソース制御システム１００’は、実施の形態１における図１のストレージリソース制御システム１００の帯域決定部１３０に相当するものとして、ソフトウェアプログラムとして実装される帯域決定部１３０’を有する。なお、帯域決定部１３０’を、実施の形態１の図１におけるストレージリソース制御システム１００に組み込んで実装することで、実施の形態１におけるストレージリソースの性能保証を行うための帯域制御情報１３２の出力機能と、本実施の形態における仮想ＤＢサーバ２３１’によるストレージリソースの使用量に対する制御を行うための帯域制御情報１３２’の出力機能とを併存させてもよい。

帯域決定部１３０’は、仮想化ソフトウェア２２０の帯域制御部２２１に設定する、仮想ＤＢサーバ２３１’における仮想ネットワーク２１２’のパス毎についての帯域上限値を決定し、帯域制御情報１３２’として出力する。ここでは例えば、図示しない運用管理システム等を利用して予め測定された、各物理サーバ２１０の（物理）ネットワーク２１２およびストレージサーバ２４０についてのパフォーマンスに係る測定情報であるＤＢ測定情報１１１’を入力とし、所定の計算方法に従って、各ボリュームにアクセスするための仮想ネットワークパス毎の帯域使用量の上限値を決定して出力する。ＤＢ測定情報１１１’については、例えば、仮想化ソフトウェア２２０の帯域制御部２２１による帯域制御を行わない状態で、対象の仮想ＤＢサーバ２３１’上で通常処理（ＯＬＴＰ）を行うことでデータベースに負荷をかけて測定する。

なお、ＤＢ測定情報１１１’に含まれる情報としては、例えば、ＲＥＤＯログ２１１−２の平均レコードサイズ、ＴＰＳ（Transaction Per Second：１秒あたりのトランザクション処理件数）数、ＲＥＤＯログ２１１−２のログスイッチの平均時間間隔、（物理）ネットワーク２１２におけるインバウンド／アウトバウンドの帯域最大使用量などが挙げられる。

帯域決定部１３０’によって出力される帯域制御情報１３２’の内容を、実施の形態１の場合と同様に、ストレージリソース制御システム１００’による自動もしくは管理者等による手動によって仮想化ソフトウェア２２０の帯域制御部２２１に適用し、帯域制御部２２１により仮想ＤＢサーバ２３１’における仮想ネットワーク２１２’の各ネットワークパスの帯域使用量を制御する。これにより、間接的に仮想ＤＢサーバ２３１’によるストレージサーバ２４０のリソース使用量を所定の範囲内に制御することができる。さらに、各ボリュームに対するアクセスの特性に応じてストレージリソースを効率的に配分することで、後述するように仮想ＤＢサーバ２３１’におけるスループットの安定化と向上を図ることができる。

［ボリューム毎の帯域上限値の決定方法］
以下では、ストレージサーバ２４０上のボリューム毎に、ＤＢ測定情報１１１’に基づいてどのように帯域上限値を決定するかについて説明する。まず、ＤＢデータ２１１−１へのアクセス用ネットワークパス（図５におけるｖｉｆ１．０）についてのインバウンド（リード）の帯域上限値については、通常処理（ＯＬＴＰ）におけるＤＢデータ２１１−１からのデータの読み込み量に対応した帯域とすることで、ＤＢデータ２１１−１に対する読み込みを絞る。すなわち、バッチ処理やＤＳＳ処理など一時的に大きな負荷がかかる処理についてもＤＢデータ２１１−１へのアクセスの際のリソース使用量を通常処理並みに制限する。これにより、これらの処理におけるストレージリソースの浪費を抑制することができる。

なお、バッチ処理やＤＳＳ処理におけるストレージリソースの使用量が制限されることで、これらの処理に要する時間が長くなってしまう場合もあり得るが、元来これらの処理は通常処理（ＯＬＴＰ）に比べて処理時間に対する要求は緩やかであるため多くの場合問題とはならない。

また、ＲＥＤＯログ２１１−２へのアクセス用ネットワークパス（図５におけるｖｉｆ１．１）についてのアウトバウンド（ライト）の帯域上限値についても、同様に、通常処理（ＯＬＴＰ）におけるＲＥＤＯログ２１１−２へのログの書き込み量に対応する帯域使用量とすることで、ＲＥＤＯログ２１１−２に対する書き込みを絞る。すなわち、バッチ処理やＤＳＳ処理についてもＲＥＤＯログ２１１−２へのログ書き込みの際のリソース使用量を通常処理並みに制限する。

通常処理（ＯＬＴＰ）は、処理が常時継続して行われるため、ＲＥＤＯログ２１１−２に対して常時一定量のログの書き込みが行われる。一方、バッチ処理やＤＳＳ処理については、処理量が多いことからログの書き込みも通常処理（ＯＬＴＰ）に比べて多くなる。従って、これらの処理によるＲＥＤＯログ２１１−２へのログの書き込みの際のリソース使用量を通常処理並みに制限することで、ストレージリソースの浪費を抑制することができる。なお、バッチ処理やＤＳＳ処理におけるストレージリソースの使用量が制限されることで、これらの処理に要する時間が長くなってしまう場合もあり得るが、上記のＤＢデータ２１１−１の場合と同様に多くの場合問題とはならない。

また、ＡＲＣＨログ２１１−３へのアクセス用ネットワークパス（図５におけるｖｉｆ１．２）についてのアウトバウンドの帯域上限値については、これを絞ることで通常処理（ＯＬＴＰ）によるＡＲＣＨログ２１１−３への書き込みを平滑化する。これにより、ＡＲＣＨログ２１１−３への書き込み処理がＲＥＤＯログ２１１−２へのログの書き込みを妨げることを抑止し、結果として通常処理（ＯＬＴＰ）のスループットの安定化および向上を図ることができる。

通常、ＡＲＣＨログ２１１−３へのアーカイブログの書き込みは、ＲＥＤＯログ２１１−２でのログスイッチ発生時などに短時間で多くの書き込みを行うため、その間はストレージリソースを多く消費してしまう。本実施の形態のようなマルチテナント形態のシステムでは、複数テナント（仮想ＤＢサーバ２３１’）のＡＲＣＨログ２１１−３への書き込みが同時に発生することによるレスポンス低下のリスクが、シングルテナント形態の場合と比較して高くなる。そこで、上記のようにストレージリソースの使用量を制限してＡＲＣＨログ２１１−３への書き込みを絞り、「短時間の大量書き込み」から「長時間の少量書き込み」に変更することで、上述したレスポンス低下のリスクを回避し、通常処理（ＯＬＴＰ）のスループットの安定化および向上を図る。

また、通常処理（ＯＬＴＰ）とバッチ処理やＤＳＳ処理とのＡＲＣＨログ２１１−３へのアーカイブログの書き込み間隔を比較すると、一般的に、通常処理（ＯＬＴＰ）の方が圧倒的に長い傾向がある。そこで、上記のようにストレージリソースの使用量を制限して、通常処理（ＯＬＴＰ）におけるＡＲＣＨログ２１１−３への書き込みの間隔を、書き込み待ちが発生しない程度に長くなるようにすると、必然的にバッチ処理やＤＳＳ処理におけるＡＲＣＨログ２１１−３への書き込みの際には、アーカイブログの書き込み待ちが発生し、結果としてバッチ処理やＤＳＳ処理によるストレージリソースの浪費を抑制することができる。

上記のような考え方に基づくＲＥＤＯログ２１１−２およびＡＲＣＨログ２１１−３へのアクセス用ネットワークパスについての帯域上限値の見積もりは、図５、図６に示したような仮想ネットワーク２１２’の構成をとることで、図８に示したような従来の構成をとる場合と比較して容易となる。例えば、ＲＥＤＯログ２１１−２へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値については、ＤＢ測定情報１１１’から得られる情報に基づいて、単に、
ＲＥＤＯログ２１１−２の平均レコードサイズ × ＴＰＳ数 …（１）
で見積もることができる。

また、ＲＥＤＯログ２１１−２のログスイッチ等に伴って古いＲＥＤＯログ２１１−２のログデータをＡＲＣＨログ２１１−３へ書き込む際に必要となるストレージリソースを制御するための、ＲＥＤＯログ２１１−２へのアクセス用ネットワークパスについてのインバウンドの帯域上限値、およびＡＲＣＨログ２１１−３へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値については、
ＲＥＤＯログ２１１−２のファイルサイズ
÷ ＲＥＤＯログ２１１−２のログスイッチの平均時間間隔 …（２）
で見積もることができる。これにより、通常処理（ＯＬＴＰ）におけるＡＲＣＨログ２１１−３への書き込みの間隔を、書き込み待ちが発生しない程度に長くすることができる。

なお、式（２）において、ＲＥＤＯログ２１１−２のファイルサイズは、仮想ＤＢサーバ２３１’上のＤＢＭＳでの設計情報や構成情報から取得することができる。また、ＡＲＣＨログ２１１−３へのアクセス用ネットワークパスについてのインバウンドについてはデータ量がごく僅かであるため帯域上限値の設定は特に不要である。

上記のような見積もりによってＲＥＤＯログ２１１−２やＡＲＣＨログ２１１−３へのアクセス用ネットワークパスについて帯域上限値を設定してストレージサーバ２４０のリソース使用量を制限したにもかかわらず、ログ書き込みがストレージリソースを浪費し、通常処理（ＯＬＴＰ）の処理を妨げる場合は、これらのボリュームを別のストレージ筐体に配置することで、通常処理（ＯＬＴＰ）の性能を保証することができる。

［処理フロー］
以下では、ストレージリソース制御システム１００’による処理の流れについて説明する。図７は、仮想化ソフトウェア２２０の帯域制御部２２１に対して仮想ネットワーク２１２’のネットワークパス毎に適用するための帯域制御情報１３２’を出力する処理の流れの例について概要を示したフローチャートである。

まず、図示しない運用管理システム等を利用して、予め、仮想化ソフトウェア２２０の帯域制御部２２１による仮想ネットワーク２１２’の帯域制御を行わない状態でデータベースに負荷をかけ、各物理サーバ２１０の（物理）ネットワーク２１２およびストレージサーバ２４０についてのパフォーマンスを測定してＤＢ測定情報１１１’を取得する（Ｓ２１）。次に、ＤＢ測定情報１１１’の値に基づいて、ＲＥＤＯログ２１１−２へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値を決定する（Ｓ２２）。ここでは、上記の式（１）に基づいて見積もられた値を帯域上限値とする。

次に、ＤＢ測定情報１１１’の値、および仮想ＤＢサーバ２３１’上のＤＢＭＳでの設計情報等に基づいて、ＲＥＤＯログ２１１−２へのアクセス用ネットワークパスについてのインバウンドの帯域上限値、およびＡＲＣＨログ２１１−３へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値を決定する（Ｓ２３）。ここでは、上記の式（２）に基づいて見積もられた値を帯域上限値とする。ＡＲＣＨログ２１１−３へのアクセス用ネットワークパスについてのインバウンドの帯域上限値については、上記の通り特に設定は不要であるが、適当な値を設定するようにしてもよい。

次に、ＤＢ測定情報１１１’の値、およびステップＳ２２で決定したＲＥＤＯログ２１１−２へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値に基づいて、ＤＢデータ２１１−１へのアクセス用ネットワークパスについてのインバウンドおよびアウトバウンドの帯域上限値を決定する（Ｓ２４）。ここで、例えば、インバウンドの帯域上限値については、ＤＢ測定情報１１１’から得られる（物理）ネットワーク２１２におけるインバウンドの帯域最大使用量をそのまま帯域上限値として決定する。また、アウトバウンドの帯域上限値については、
（物理）ネットワーク２１２におけるアウトバウンドの帯域最大使用量
− ＲＥＤＯログ２１１−２へのアクセス用ネットワークパスに
ついてのアウトバウンドの帯域上限値 …（３）
で見積もることができる。

最後に、ステップＳ２２〜Ｓ２４で得られた各ボリュームへのアクセス用ネットワークパスについてのインバウンド／アウトバウンドの帯域上限値を帯域制御情報１３２’として出力する（Ｓ２５）。これを仮想化ソフトウェア２２０の帯域制御部２２１に適用することで、対象の仮想ＤＢサーバ２３１’が使用するストレージサーバ２４０のリソース使用量の上限を間接的に制御し、他の仮想ＤＢサーバ２３１’が必要とするリソース使用量を侵食しないようにすることができる。また、各仮想ＤＢサーバ２３１’におけるストレージリソースの使用をボリューム毎に効率化し、スループットの安定化と向上を実現することができる。

なお、図７の処理フローにおいて、例えばステップＳ２２〜Ｓ２４の処理順序はこれに限られるものではなく、各帯域上限値の決定順序は適宜変更することができる。また、実施の形態１の場合と同様に、上記の一連の処理を定期的に自動で実行することで、リソースプール２００の各ストレージサーバ２４０において、負荷状況に合わせて各仮想ＤＢサーバ２３１’のリソース使用量を動的に最適化して割り当てることも可能となる。

なお、本実施の形態では、ＤＢ測定情報１１１’におけるＴＰＳ数や、ＲＥＤＯログ２１１−２の平均レコードサイズ、ログスイッチの平均時間間隔といったパフォーマンス情報を測定して得ることで、対象の仮想ＤＢサーバ２３１’に対して必要なストレージリソースを割り当てることを想定している。一方、例えば、新規の仮想ＤＢサーバ２３１’を構築する場合や、既存の仮想ＤＢサーバ２３１’を拡張する場合には、アプリケーション等の分析によって得られるこれらのパフォーマンス情報の予測値を利用することで、必要となるストレージリソース（仮想ネットワーク２１２’の帯域上限値）の予測値を得ることができる。これにより、実施の形態１における割当判定部１４０での処理（図４における割当情報１４２の出力処理）と同様の処理により、仮想ＤＢサーバ２３１’をいずれの物理サーバ２１０（ストレージサーバ２４０）に割り当てるかを判定することができる。

以上に示したように、本発明の実施の形態２であるストレージリソース制御システム１００’によれば、リソースプール２００において、仮想ＤＢサーバ２３１’が使用するストレージサーバ２４０上の各ボリュームについて、仮想ネットワーク２１２’によってそれぞれ独立したネットワークパスを介してアクセスするよう仮想ＤＢサーバ２３１’を構成する。これにより、実施の形態１と同様に、各仮想ＤＢサーバ２３１’によるストレージサーバ２４０（ストレージサーバ２４０上の各ボリューム）のリソースの使用可能量を、仮想化ソフトウェア２２０が通常有するネットワーク帯域制御機能（帯域制御部２２１）を用いて容易に制御し、他の仮想ＤＢサーバ２３１’に使用可能量として割り当てられているストレージリソースを侵食しないようにすることで、「最低保証型」の性能保証機能を実現することが可能となる。

また、仮想ＤＢサーバ２３１’によるストレージサーバ２４０上の各ボリュームに対するアクセスパターンに応じてストレージリソースをボリューム毎に効率的に配分することで、例えば、バッチ処理やＤＳＳ処理など一時的に大きな負荷がかかる処理が複数テナントで同時に実行されるような場合でも、これらの処理によるストレージリソースの浪費を抑制し、通常処理（ＯＬＴＰ）の性能を劣化させることなく実行することが可能となり、仮想ＤＢサーバ２３１’におけるスループットの安定化と向上を図ることができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明は、ストレージ機器のリソース使用量について最低保証型の性能保証を行うよう制御するためのストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法に利用可能である。

１…情報処理システム、
１００、１００’…ストレージリソース制御システム、
１１０…モデル作成部、１１１…リソース使用状況、１１１’…ＤＢ測定情報、１１２…線形モデル、
１２０…リソース予測部、１２１…Ｉ／Ｏ特性、１２２…予測使用量、
１３０、１３０’…帯域決定部、１３１…設定ポリシー、１３２、１３２’…帯域制御情報、
１４０…割当判定部、１４２…割当情報、
２００…リソースプール、
２１０（２１０ａ、２１０ｂ）…物理サーバ（物理サーバＡ、物理サーバＢ）、２１１（２１１ａ、２１１ｂ）…ストレージ（ストレージＡ、ストレージＢ）、２１１−１…ＤＢデータ、２１１−２…ＲＥＤＯログ、２１１−３…ＡＲＣＨログ、２１２（２１２ａ、２１２ｂ）…ネットワーク（ネットワークＡ、ネットワークＢ）、２１２’…仮想ネットワーク、２２０（２２０ａ、２２０ｂ）…仮想化ソフトウェア（仮想化ソフトウェアＡ、仮想化ソフトウェアＢ）、２２１（２２１ａ、２２１ｂ）…帯域制御部（帯域制御部Ａ、帯域制御部Ｂ）、２３１（２３１ａ１、２３１ａ２、２３１ｂ１）…仮想サーバ（テナントａ１用仮想サーバ、テナントａ２用仮想サーバ、テナントｂ１用仮想サーバ）、２３１’…仮想ＤＢサーバ、２４０…ストレージサーバ。

Claims (6)

1. ネットワークを介してストレージサーバが接続された１つ以上の物理サーバ上において、前記ネットワークに対する帯域制御機能を有する仮想化ソフトウェアにより、テナント毎に仮想化された複数の仮想データベースサーバが前記物理サーバおよび前記ストレージサーバのリソースを共有する形態で稼働するリソースプールに対して、前記帯域制御機能によって前記仮想データベースサーバによる前記ネットワークの帯域の使用量を制御することによって、前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御するためのストレージリソース制御システムであって、
   前記仮想データベースサーバは、前記ストレージサーバ上に有する、前記仮想データベースサーバによる作業履歴ログを保持する作業履歴ログボリューム、過去の作業履歴ログをアーカイブするアーカイブログボリューム、およびその他のデータを保持するＤＢデータボリュームに対して、それぞれ異なるネットワークパスによりアクセス可能なように仮想ネットワークが構成されており、
   該ストレージリソース制御システムは、前記ネットワークおよび前記ストレージサーバについてのパフォーマンスに係る測定情報、および前記仮想データベースサーバの構成情報に基づいて、前記仮想化ソフトウェアの前記帯域制御機能に対して設定する、前記ストレージサーバ上の各ボリュームにアクセスするための前記仮想ネットワークにおけるネットワークパス毎の帯域使用量の上限値を決定して出力する帯域決定部を有することを特徴とするストレージリソース制御システム。
2. 請求項１に記載のストレージリソース制御システムにおいて、
   前記帯域決定部は、前記ＤＢデータボリュームへのアクセス用のネットワークパスについてのインバウンドの帯域使用量の上限値については、前記仮想データベースサーバで実行されるオンライントランザクション処理からなる通常処理における前記ＤＢデータボリュームからのデータの読み込み量に対応した帯域とすることを特徴とするストレージリソース制御システム。
3. 請求項１に記載のストレージリソース制御システムにおいて、
   前記帯域決定部は、前記作業履歴ログボリュームへのアクセス用のネットワークパスについてのアウトバウンドの帯域使用量の上限値については、前記仮想データベースサーバで実行されるオンライントランザクション処理からなる通常処理における前記作業履歴ログボリュームへのログの書き込み量に対応した帯域とすることを特徴とするストレージリソース制御システム。
4. 請求項１に記載のストレージリソース制御システムにおいて、
   前記帯域決定部は、前記アーカイブログボリュームへのアクセス用のネットワークパスについてのアウトバウンドの帯域使用量の上限値については、前記仮想データベースサーバで実行されるオンライントランザクション処理からなる通常処理における前記アーカイブログボリュームへの書き込みの間隔が、書き込み待ちが発生しない範囲となるような帯域とすることを特徴とするストレージリソース制御システム。
5. ネットワークを介してストレージサーバが接続された１つ以上の物理サーバ上において、前記ネットワークに対する帯域制御機能を有する仮想化ソフトウェアにより、テナント毎に仮想化された複数の仮想データベースサーバが前記物理サーバおよび前記ストレージサーバのリソースを共有する形態で稼働するリソースプールに対して、前記帯域制御機能によって前記仮想データベースサーバによる前記ネットワークの帯域の使用量を制御することによって、前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御するためのストレージリソース制御システムとしてコンピュータを機能させるストレージリソース制御プログラムであって、
   前記仮想データベースサーバは、前記ストレージサーバ上に有する、前記仮想データベースサーバによる作業履歴ログを保持する作業履歴ログボリューム、過去の作業履歴ログをアーカイブするアーカイブログボリューム、およびその他のデータを保持するＤＢデータボリュームに対して、それぞれ異なるネットワークパスによりアクセス可能なように仮想ネットワークが構成されており、
   該ストレージリソース制御プログラムは、前記ネットワークおよび前記ストレージサーバについてのパフォーマンスに係る測定情報、および前記仮想データベースサーバの構成情報に基づいて、前記仮想化ソフトウェアの前記帯域制御機能に対して設定する、前記ストレージサーバ上の各ボリュームにアクセスするための前記仮想ネットワークにおけるネットワークパス毎の帯域使用量の上限値を決定して出力する帯域決定処理を実行することを特徴とするストレージリソース制御プログラム。
6. ネットワークを介してストレージサーバが接続された１つ以上の物理サーバ上において、仮想化ソフトウェアによりテナント毎に仮想化された複数の仮想データベースサーバが前記物理サーバおよび前記ストレージサーバのリソースを共有する形態で稼働するリソースプールに対して、前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御するストレージリソース制御方法であって、
   前記仮想データベースサーバにおいて、前記ストレージサーバ上に有する、前記仮想データベースサーバによる作業履歴ログを保持する作業履歴ログボリューム、過去の作業履歴ログをアーカイブするアーカイブログボリューム、およびその他のデータを保持するＤＢデータボリュームに対して、それぞれ異なるネットワークパスによりアクセス可能なように仮想ネットワークを構成し、
   コンピュータシステムにより、前記仮想化ソフトウェアが有する前記仮想ネットワークに対する帯域制御機能に対して、前記ネットワークおよび前記ストレージサーバについてのパフォーマンスに係る測定情報、および前記仮想データベースサーバの構成情報に基づいて決定した、前記ストレージサーバ上の各ボリュームにアクセスするための前記仮想ネットワークにおけるネットワークパス毎の帯域使用量の上限値を設定し、前記帯域制御機能によって前記仮想データベースサーバによる前記仮想ネットワークにおけるネットワークパス毎の帯域の使用量を制御することによって、間接的に前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御することを特徴とするストレージリソース制御方法。

Images