説明

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

【課題】各テナントの仮想DBサーバによるストレージリソースの使用量について「最低保証型」の性能保証を容易に行うことができるストレージリソース制御システムを提供する。
【解決手段】帯域制御部221によって仮想DBサーバ231’によるネットワークの帯域の使用量を制御することによってストレージサーバ240のリソースの使用可能量を制御するためのストレージリソース制御システム100’であって、仮想DBサーバ231’は、ストレージサーバ240上のREDOログ211−2、ARCHログ211−3、およびDBデータ211−1に対してそれぞれ異なるネットワークパスによりアクセス可能なように仮想ネットワーク212’が構成されており、DB測定情報111’および仮想DBサーバ231’の構成情報に基づいて帯域制御部221に対して設定するネットワークパス毎の帯域使用量の上限値を決定して出力する帯域決定部130’を有する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、マルチテナント形態のコンピュータシステムにおける各テナントのリソース使用量の制御技術に関し、特に、ストレージ機器のリソース使用量について最低保証型の性能保証を行うよう制御するためのストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法に適用して有効な技術に関するものである。
【背景技術】
【0002】
近年、企業等においては、ITコスト削減のために、クラウドコンピューティング環境の利用などによってコンピュータリソースを他の企業や他の部門、プロジェクト等との間で共有する形態(マルチテナント形態)が注目されている。特に、エンタープライズ用途でマルチテナント形態が採用される場合、データセンター等においてコンピュータリソースを運用・管理するITベンダーとしては、各テナントに対する「性能保証」が重要な課題となる。
【0003】
一般的に、「性能保証」を行うための制御方法は、「優先制御型」と「最低保証型」の2つに大きく分類される。「優先制御型」は、いわゆるベストエフォート型の保証形態であり、各テナントに対して使用可能なリソース量の目安は設定されるものの、例えば、他のテナントでの処理も含めて、コンピュータリソースが不足する状況となった場合、優先度の低いテナントに割り当てられたリソースは優先度の高い処理を行うテナントに優先的に割り当てられ侵食される。一方、「最低保障型」では、各テナントは少なくとも使用可能として割り当てられた範囲でのリソースの使用は保証される(他のテナントでの処理によって侵食されない)。
【0004】
物理サーバのリソース(CPU(Central Processing Unit)やメモリ等)を、各テナントのアプリケーションが稼働する複数の仮想サーバによって共有するための手段としては、例えばVMware(登録商標)などを始めとして様々な仮想化ソフトウェア製品が存在し、性能保証を行うための制御手段も十分揃っている。一方で、ストレージ機器(特にミッドレンジ以下)のリソースの共有に関しては、「優先制御型」の性能保証機能を有する製品は存在するものの、一般的に「最低保証型」の性能保証機能を有するものはほとんど存在せず、実現のためには何らかの仕組みを実装する必要がある。
【0005】
これに関する技術として、例えば特開2010−122814号公報(特許文献1)には、アプリケーションに割り当てられる論理ボリュームを提供するディスクアレイグループを備えたストレージ装置について、ストレージ管理部は、アレイグループのスループット、レスポンスタイムと、記憶容量とを保持しており、論理ボリュームについて要求される、スループットと記憶容量との比である性能密度と、記憶容量の要件とを受け付け、前記アレイグループから前記スループットの値を上限として、受け付けた前記性能密度と容量要件に基づいて前記スループットを論理ボリュームに割り当て、割り当てたスループットと、受け付けた前記容量要件とに基づいて決定した記憶容量を、前記論理ボリュームに割り当てることで、ストレージ資源を性能面、容量面でバランスよく効率的に記憶領域として割り当てるストレージシステムが記載されている。
【先行技術文献】
【特許文献】
【0006】
【特許文献1】特開2010−122814号公報
【発明の概要】
【発明が解決しようとする課題】
【0007】
上述したように、ストレージ機器のリソース共有において「最低保証型」の性能保証機能を実現するためには、何らかの仕組みを実装する必要がある。しかしながら、特許文献1に記載したような技術では、要求されるリソースを論理ボリュームに割り当てて、その範囲内で制御する仕組みは提供されるものの、特に、ストレージがデータベース(DB)サーバにおいて利用されるような場合は考慮されていない。DBサーバのようなアプリケーションの場合、DBサーバからのストレージに対する入出力特性(ストレージに対するアクセスパターン)が複数混在することになるため、アプリケーション(DBサーバ)に対してストレージリソースの使用量を適切に割り当てて制御することは困難である。
【0008】
そこで本発明の目的は、各テナントのストレージ機器のリソース使用量について「最低保証型」の性能保証を容易に行うことができるストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法を提供することにある。特に、DBサーバによるストレージリソースの使用量についても「最低保証型」の性能保証を行うことができるストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法を提供することにある。
【0009】
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
【課題を解決するための手段】
【0010】
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
【0011】
本発明の代表的な実施の形態によるストレージリソース制御システムは、ネットワークを介してストレージサーバが接続された1つ以上の物理サーバ上において、前記ネットワークに対する帯域制御機能を有する仮想化ソフトウェアにより、テナント毎に仮想化された複数の仮想データベースサーバが前記物理サーバおよび前記ストレージサーバのリソースを共有する形態で稼働するリソースプールに対して、前記帯域制御機能によって前記仮想データベースサーバによる前記ネットワークの帯域の使用量を制御することによって、前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御するためのストレージリソース制御システムであって、以下の特徴を有するものである。
【0012】
すなわち、前記仮想データベースサーバは、前記ストレージサーバ上に有する、前記仮想データベースサーバによる作業履歴ログを保持する作業履歴ログボリューム、過去の作業履歴ログをアーカイブするアーカイブログボリューム、およびその他のデータを保持するDBデータボリュームに対して、それぞれ異なるネットワークパスによりアクセス可能なように仮想ネットワークが構成されている。
【0013】
また、該ストレージリソース制御システムは、前記ネットワークおよび前記ストレージサーバについてのパフォーマンスに係る測定情報、および前記仮想データベースサーバの構成情報に基づいて、前記仮想化ソフトウェアの前記帯域制御機能に対して設定する、前記ストレージサーバ上の各ボリュームにアクセスするための前記仮想ネットワークにおけるネットワークパス毎の帯域使用量の上限値を決定して出力する帯域決定部を有することを特徴とする。
【0014】
また、本発明は、コンピュータを上記のようなストレージリソース制御システムとして機能させるプログラムにも適用することができる。また、本発明は、ネットワークを介してストレージサーバが接続された1つ以上の物理サーバ上において、仮想化ソフトウェアによりテナント毎に仮想化された複数の仮想データベースサーバが前記物理サーバおよび前記ストレージサーバのリソースを共有する形態で稼働するリソースプールに対して、前記仮想データベースサーバに割り当てられた前記ストレージサーバのリソースの使用可能量を制御するストレージリソース制御方法にも適用することができる。
【発明の効果】
【0015】
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
【0016】
本発明の代表的な実施の形態によれば、各テナントのストレージ機器のリソース使用量について「最低保証型」の性能保証を容易に行うことが可能となる。特に、DBサーバによるストレージのリソース使用量についても「最低保証型」の性能保証を行うことが可能となることで、他のテナントでの処理により受ける影響を低減するとともに、データベース処理におけるスループットの向上および安定化を図ることが可能となる。
【図面の簡単な説明】
【0017】
【図1】本発明の実施の形態1であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。
【図2】本発明の実施の形態1におけるモデル作成部によって作成される線形モデルのうちの入出力処理量モデルの例を示した図である。
【図3】本発明の実施の形態1における帯域制御情報を出力する処理の流れの例について概要を示したフローチャートである。
【図4】本発明の実施の形態1における割当情報を出力する処理の流れの例について概要を示したフローチャートである。
【図5】本発明の実施の形態2における物理サーバ上に仮想DBサーバを構築する際の構成例について概要を示した図である。
【図6】本発明の実施の形態2であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。
【図7】本発明の実施の形態2における帯域制御情報を出力する処理の流れの例について概要を示したフローチャートである。
【図8】物理サーバ上に仮想DBサーバを構築する際の一般的な構成例について概要を示した図である。
【発明を実施するための形態】
【0018】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【0019】
<実施の形態1>
本発明の実施の形態1であるストレージリソース制御システムを有する情報処理システムでは、ストレージ機器が接続された物理サーバ上に各テナント用の複数の仮想サーバを構築してマルチテナント形態として運用されるコンピュータシステムに対して、各仮想サーバによるストレージリソースの使用可能量を、仮想化ソフトウェア製品が通常有するネットワーク帯域制御機能を用いることで容易に制御する。すなわち、各仮想サーバについて、物理サーバとストレージ機器との間のネットワークの帯域の使用量に対してネットワーク帯域制御機能によってキャップを設定することで、間接的に各仮想サーバによるストレージリソースの使用可能量を制御する。
【0020】
各仮想サーバによるストレージリソースの使用可能量をそれぞれ所定の範囲内に制御することにより、各仮想サーバが他の仮想サーバに使用可能量として割り当てられたストレージリソースまで侵食して使用すること抑止することができ、「最低保証型」の性能保証機能を実現することができる。なお、本実施の形態において、制御の対象となるストレージリソースとはストレージ機器における単位時間当たりのリソースの使用量(例えば、ストレージ機器のCPU使用率や、ディスクビジー率など)を指し、使用するディスク容量は含まないものとする。
【0021】
ここで、仮想化ソフトウェア製品のネットワーク帯域制御機能を用いて間接的にストレージリソースの使用可能量を所定の範囲内に制御するという場合、少なくとも、物理サーバとストレージ機器との間のネットワーク帯域の使用量と、ストレージリソースの使用量との相関関係を把握しておく必要がある。そこで、本実施の形態では、ネットワーク帯域の使用量とストレージリソースの使用量との相関関係についてモデル(帯域使用量モデル)を作成し、当該モデルに基づいてストレージリソースの使用量の上限(使用可能量)に対応するネットワーク帯域の使用量の上限を決定する。
【0022】
本実施の形態では、各仮想サーバに対して、ストレージリソースの使用量の上限(使用可能量)を割り当てることになるが、これは、各仮想サーバ上で稼働するアプリケーションがその入出力処理のためにどれだけのストレージリソースを必要とするかによって定まる。ここで、各アプリケーションが必要とするストレージリソースの使用量を判断するためには、少なくとも、ストレージにおける入出力処理量とストレージリソースの使用量との相関関係を把握しておく必要がある。そこで、本実施の形態では、ストレージにおける入出力処理量とストレージリソースの使用量との相関関係についてもモデル(入出力処理量モデル)を作成し、当該モデルに基づいて、各仮想サーバで実行されるアプリケーションの入出力特性(入出力処理量)に応じて必要とされるストレージリソースの使用量を予測する。
【0023】
上記の入出力処理量モデルと帯域使用量モデルを利用することで、各仮想サーバがアプリケーションでの入出力処理のために必要とするストレージリソースの使用量(最大使用量)に対応したネットワーク帯域の使用量を予測することができる。予測されたネットワーク帯域の使用量の情報を、帯域制御情報として仮想化ソフトウェアのネットワーク帯域制御機能に適用することで、各仮想サーバに割り当てられるストレージリソースの使用可能量を、アプリケーションの入出力特性から得られる最大使用量に応じて最適な値に設定することが可能となる。
【0024】
[システム構成]
図1は、本実施の形態であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。図1において、情報処理システム1は、例えばITベンダー等が、データセンター等の施設において、クラウドコンピューティング環境として多数のサーバ機器等からなるコンピュータリソースをリソースプール200として運用・管理し、そのコンピュータリソースを他の企業や他の部門、プロジェクト等のユーザ(テナント)に対して、テナント間で共有する形態(マルチテナント形態)によりサービスとして提供するものである。
【0025】
本実施の形態の情報処理システム1は、さらに、リソースプール200によって提供されるストレージリソースについて、各テナントに対して「最低保証型」の性能保証機能を提供するため、各仮想サーバによるストレージリソースの使用量を所定の範囲内に制御するための情報を出力する機能を有するストレージリソース制御システム100を有する。
【0026】
情報処理システム1において、リソースプール200は、複数の物理サーバ210(図1の例では、物理サーバA(210a)および物理サーバB(210b))やストレージ211(図1の例ではストレージA(211a)およびストレージB(211b))によって各テナントに対して提供される管理対象としてのコンピュータリソースの全体を総称するものである。各物理サーバ210は、それぞれ、仮想化ソフトウェア220(図1の例では仮想化ソフトウェアA(220a)および仮想化ソフトウェアB(220b))によって仮想化され、その上でテナント毎に複数の仮想サーバ231(図1の例では、テナントa1用仮想サーバ231a1、テナントa2用仮想サーバ231a2およびテナントb1用仮想サーバ231b1)が稼働している。
【0027】
仮想化ソフトウェア220としては、ベンダー等から提供されている一般的なソフトウェア(例えば、VMwareやXen(登録商標)など)を利用することができる。また、仮想サーバ231上で稼働するゲストOS(Operating System)の種類なども特に限定されない。上記のような一般的な仮想化ソフトウェア220は、通常、各仮想サーバ231が使用するネットワークの帯域が、設定された(割り当てられた)上限値を超えないように制御するネットワーク帯域制御機能を有している。本実施の形態では、この機能は仮想化ソフトウェア220における帯域制御部221(図1の例では、帯域制御部A(221a)および帯域制御部B(221b))により提供されるものとする。
【0028】
各物理サーバ210には、それぞれ、機器の内部もしくは外部のネットワーク212(図1の例ではネットワークA(212a)およびネットワークB(212b))を介してストレージ211(図1の例ではストレージA(211a)およびストレージB(211b))が接続されている。
【0029】
以上のような構成により、各テナントの仮想サーバ231は、それぞれ、物理サーバ210やストレージ211のコンピュータリソース(本実施の形態では特に、CPU使用率やディスクビジー率など単位時間あたりの使用率を割り当てることによって他のテナントと共有する形態となるもの)を、仮想化ソフトウェア220を介して共有する。
【0030】
なお、本実施の形態では、ストレージ211は、特に「最低保証型」の性能保証機能を有さないミッドレンジ以下のストレージ機器を対象とする。これらのストレージ211は、例えば、物理サーバ210にローカル接続されたストレージ機器や、iSCSI(Internet Small Computer System Interface)等を利用して構成されたSAN(Storage Area Network)、NFS(Network File System)等を利用して構成されたNAS(Network Attached Storage)など、ストレージ211自身がCPUを有してデータの読み書きを行うものであり、上記の仮想化ソフトウェア220の帯域制御部221によるネットワーク帯域制御機能により、物理サーバ210とストレージ211との間のネットワーク212の帯域制御が可能な構成とすることができるものであれば特に限定されない。
【0031】
一方、ストレージリソース制御システム100は、例えば、サーバやPC(Personal Computer)などのコンピュータシステムにより構成され、ソフトウェアプログラムとして実装されるモデル作成部110、リソース予測部120、帯域決定部130および割当判定部140の各部を有する。これら各部は、それぞれが独立したプログラムとして実装されてもよいし、複数の部がまとまって1つのプログラムとして実装されてもよい。ストレージリソース制御システム100は、リソースプール200内の各物理サーバ210と図示しないネットワークを介して接続可能であってもよいし、オフラインで実装されていてもよい。また、独立したシステムとしてではなく他の運用管理システム等の一部として組み込まれて実装されてもよい。
【0032】
本実施の形態では、上述したように、ストレージリソース制御システム100によって、各仮想サーバ231がアプリケーションでの入出力処理のために必要とするストレージリソースの使用量に対応したネットワーク212の帯域の使用可能量を予測し、これを帯域制御情報として出力する。これを仮想化ソフトウェア220の帯域制御部221に適用することで、間接的に各仮想サーバ231のストレージリソースの使用可能量を制御し、「最低保証型」の性能保証機能を実現することができる。
【0033】
ストレージリソース制御システム100のモデル作成部110は、各仮想サーバ231によるネットワーク212の帯域の使用可能量を予測するために用いる、上述した入出力処理量モデルと帯域使用量モデルを作成する。詳細については後述するが、ここでは例えば、図示しない運用管理システム等を利用して測定もしくは収集し取得される、リソースプール200内の各物理サーバ210のネットワーク212およびストレージ211についてのリソースの使用状況に係る情報であるリソース使用状況111を入力とし、ストレージ211における入出力処理量とストレージリソースの使用量についてのモデルである入出力処理量モデルと、ネットワーク212の帯域使用量とストレージリソースの使用量についてのモデルである帯域使用量モデルからなる線形モデル112を作成して出力する。
【0034】
リソース予測部120は、上記の線形モデル112に基づいて、各テナントの仮想サーバ231がアプリケーションでの入出力処理のために必要とするストレージ211のリソース使用量に対応したネットワーク212の帯域使用量を予測する。ここでは、各仮想サーバ231上で稼働するアプリケーションについて予め分析されている入出力(I/O)の特性についての情報であるI/O特性121を入力として、線形モデル112のうちの入出力処理量モデルに基づいて、各仮想サーバ231(もしくはアプリケーション)が必要とするストレージ211のリソース使用量を予測する。さらに、線形モデル112のうちの帯域使用量モデルに基づいて、必要とするストレージ211のリソース使用量に対応するネットワーク212の帯域使用量を予測し、予測使用量122として出力する。
【0035】
帯域決定部130は、予め定義された、帯域制御値の設定に係るポリシーの情報である設定ポリシー131に基づいて、上記の予測使用量122から、各仮想化ソフトウェア220の帯域制御部221に設定する、各仮想サーバ231についての帯域制御値を決定し、帯域制御情報132として出力する。この帯域制御情報132の内容を、ストレージリソース制御システム100による自動もしくは管理者等による手動によって各仮想化ソフトウェア220の帯域制御部221に適用し、帯域制御部221により各仮想サーバ231によるネットワーク212の帯域使用量を制御する。これにより、間接的に各仮想サーバ231によるストレージ211のリソース使用量を所定の範囲内に制御することができる。
【0036】
割当判定部140は、特定の新規または既存の仮想サーバ231について、どの物理サーバ210上に構築することができるか(どのストレージ211に対して割り当てることができるか)を判定する。例えば、新規に構築する予定の仮想サーバC(図示しない)についてリソース予測部120により得られた予測使用量122の情報と、各物理サーバ210のストレージ211の現状でのリソース使用状況111の情報とに基づいて、ストレージA(211a)、ストレージB(211b)のいずれに割り当てることができるかを判定し、判定結果を割当情報142として出力する。
【0037】
また例えば、既存の仮想サーバ(例えばテナントa2用仮想サーバ231a2)においてアプリケーションでの処理内容や処理量を拡張したいというような場合、拡張するアプリケーションにおいて増加する入出力処理量に対応するストレージ211のリソース使用量をリソース予測部120によって予測して予測使用量122の情報を得る。
【0038】
この予測使用量122の情報と、各物理サーバ210のストレージ211の現状でのリソース使用状況111の情報とに基づいて、テナントa2用仮想サーバ231a2が現在のストレージA(211a)を利用したまま拡張することが可能なのか、物理サーバB(210b)のストレージB(211b)など他のストレージ211に移行して割り当てた上で拡張する必要があるのかなどを判定し、判定結果を割当情報142として出力する。
【0039】
出力された割当情報142に基づいて、仮想サーバ231を対象の物理サーバ210(ストレージ211)に割り当てて構築もしくは拡張する。さらに、当該仮想サーバ231に対する帯域制御情報132を作成して、対象の仮想化ソフトウェア220の帯域制御部221に適用することで、「最低保証型」の性能保証機能を維持することができる。
【0040】
[線形モデル(入出力処理量モデル、帯域使用量モデル)]
以下では、図1のストレージリソース制御システム100のモデル作成部110が作成する線形モデル112について説明する。線形モデル112のうち、例えば入出力処理量モデルの作成に際しては、まずモデル作成部110は、図示しない運用管理システム等により測定・収集されたリソース使用状況111の情報から、ストレージ211のリソース使用量と、ストレージ211における入出力処理量を取得し、これらをストレージ211に対するアクセス種別毎に集計する。
【0041】
ここで、ストレージ211のリソースとしては、上述したように、CPU使用率やディスクビジー率など、単位時間(秒)あたりの使用率で表されるリソースが挙げられる。また、ストレージ211における入出力処理量としては、例えば、単位時間(秒)あたりの入出力処理数(IOPS(Input Output Per Second))を使用することができる。このIOPSの値は、例えば、ネットワーク212上のパケットを解析することにより間接的に取得することができる。ストレージ211に対するアクセス種別としては、例えば、同期/非同期のシーケンシャルライト、同期/非同期のランダムライト、シーケンシャルリード、ランダムリードなどが挙げられる。
【0042】
図2は、図1においてモデル作成部110によって作成される線形モデル112のうちの入出力処理量モデルの例を示した図である。ここでは、アクセス種別のうち同期シーケンシャルライトを例として、CPU使用率およびディスクビジー率とIOPSとの関係をそれぞれプロットしたものを示している。モデル作成部110は、これらのデータに基づいてCPU使用率およびディスクビジー率についてそれぞれ線形近似して入出力処理量モデルを作成する。線形近似の手法は特に限定されず、例えば最小二乗法などを用いることができる。
【0043】
線形モデル112のうちの帯域使用量モデルの作成についても上記と同様であり、モデル作成部110は、図示しない運用管理システム等により測定・収集されたリソース使用状況111の情報から、ネットワーク212の帯域使用量とストレージ211のリソース使用量を取得し、これらをストレージ211に対するアクセス種別毎に集計する。ネットワーク212の帯域使用量としては、単位時間(秒)あたりの伝送データ量(bps)を使用することができる。これらのデータについて、図2の例と同様に、アクセス種別毎にCPU使用率およびディスクビジー率と帯域使用量との関係をそれぞれプロットし、最小二乗法等により線形近似して帯域使用量モデルを作成する。
【0044】
上記のような線形モデル112を利用することで、入出力処理量モデルから、仮想サーバ231上で稼働するアプリケーションの入出力処理量に対して必要となるストレージ211のリソース使用量を予測することができ、さらに、帯域使用量モデルから、予測されたストレージ211のリソース使用量に対応するネットワーク212の帯域使用量を予測することが可能となる。
【0045】
[処理フロー]
以下では、ストレージリソース制御システム100による処理の流れについて説明する。図3は、各仮想化ソフトウェア220の帯域制御部221に適用するための帯域制御情報132を出力する処理の流れの例について概要を示したフローチャートである。当該処理を行う前の事前準備として、各ストレージ211についての上述した線形モデル112の作成は行われているものとする。
【0046】
処理を開始すると、まず、帯域制御情報132により制御する対象となる仮想サーバ231上で稼働するアプリケーションのストレージ211に対する入出力特性を分析し、I/O特性121を取得してストレージリソース制御システム100に入力する(S01)。ここでは、I/O特性121として例えば、アプリケーションの処理内容から想定もしくは実測される、ストレージ211に対するアクセス種別毎の入出力処理量(IOPS)を取得する。例えば、
・同期ランダムライト →1,000IOPS
・ランダムリード →2,000IOPS
・その他のアクセス種別→なし
などの情報を得る。当該分析は、ストレージリソース制御システム100の外部で管理者等が行ってもよいし、分析用のソフトウェアプログラムを実装してもよい。
【0047】
次に、リソース予測部120は、I/O特性121を入力として、モデル作成部110により予め作成されている線形モデル112のうちの入出力処理量モデルを利用して、アプリケーションの入出力特性に対して必要となるストレージ211のリソース使用量を予測する(S02)。例えば、図2に示したような線形近似された入出力処理量モデルから、
・CPU使用率
・同期ランダムライト(1,000IOPS)→10%
・ランダムリード(2,000IOPS) →15%
・ディスクビジー率
・同期ランダムライト(1,000IOPS)→5%
・ランダムリード(2,000IOPS) →10%
というような予測値を得る。
【0048】
次に、リソース予測部120は、ステップS02で得たリソース使用量の予測値に対して、線形モデル112のうちの帯域使用量モデルを利用して、必要となるストレージ211のリソース使用量に対して必要となるネットワーク212の帯域使用量を予測する(S03)。例えば、図2に示したものと同様に線形近似された帯域使用量モデルから、
・CPU使用率から予測したネットワーク212の帯域使用量
・同期ランダムライト(10%)→100Mbps
・ランダムリード(15%) →300Mbps
・ディスクビジー率から予測したネットワーク212の帯域使用量
・同期ランダムライト(5%) →50Mbps
・ランダムリード(10%) →200Mbps
というような予測値を得る。
【0049】
最後に、帯域決定部130は、ステップS03で得たネットワーク212の帯域使用量の予測値から、設定ポリシー131に基づいて、帯域制御部221に適用する帯域上限値を決定し、帯域制御情報132として出力する(S04)。例えば、設定ポリシー131として、「各ストレージリソース(CPU使用率、ディスクビジー率)毎のネットワーク212の帯域使用量の予測値において最大値を上限値とする」というように設定されているものとすると、
・帯域上限値
・アウトバウンド(ライト)→100Mbps
・インバウンド(リード) →300Mbps
といような値を得る。
【0050】
これらの値を対象の仮想サーバ231に対する帯域制御情報132として出力し、仮想化ソフトウェア220の帯域制御部221に適用することで、対象の仮想サーバ231のストレージ211のリソース使用量の上限を間接的に制御し、他の仮想サーバ231が必要とするリソース使用量を侵食しないようにする。これにより、ストレージ211全体として、各テナント(仮想サーバ231)間で「最低保証型」の性能保証機能を実現することができる。
【0051】
なお、例えば、事前準備での線形モデル112の作成も含めた上記の一連の処理を定期的に自動で実行することで、リソースプール200の各ストレージ211において、負荷状況に合わせて各仮想サーバ231のリソース使用量を動的に最適化して割り当てることも可能となる。
【0052】
図4は、本実施の形態の線形モデル112(入出力処理量モデル)を利用することで、アプリケーションの入出力処理量から仮想サーバ231が必要とするストレージ211のリソース使用量を把握することが可能となることを利用した例として、特定の仮想サーバ231をいずれの物理サーバ210(ストレージ211)に割り当てるかを判定して割当情報142を出力する処理の流れの例について概要を示したフローチャートである。
【0053】
この処理では、例えば、新規に仮想サーバ231を構築する際に、複数の物理サーバ210(ストレージ211)のうちいずれに割り当てるかの判定や、既存の仮想サーバ231の処理内容や処理量を拡張するような場合に、現状割り当てられている物理サーバ210(ストレージ211)上で可能なのか、他のストレージ211に移行した上で拡張する必要があるのかなどの判定を行うための情報を得ることができる。
【0054】
当該処理を行う前の事前準備として、図3に示した例と同様に、各ストレージ211についての上述した線形モデル112の作成は行われているものとする。また、各ストレージ211の現在のリソースの使用状況がリソース使用状況111として得られているものとする。例えば、
・ストレージA(211a)
・CPU使用率 →80%
・ディスクビジー率→60%
・ストレージB(211b)
・CPU使用率 →20%
・ディスクビジー率→20%
というような値が現在のリソース使用状況111として得られているものとする。
【0055】
処理を開始すると、まず、対象となる仮想サーバ231上で稼働するアプリケーションのストレージ211に対する入出力特性を分析し、増加分のI/O特性121を取得してストレージリソース制御システム100に入力する(S11)。I/O特性121については、図3に示した例と同様であるが、新規の仮想サーバ231を構築する場合は、当該仮想サーバ231上で稼働する新たなアプリケーションの処理内容から想定される、ストレージ211に対するアクセス種別毎の入出力処理量を取得する。また、既存の仮想サーバ231を拡張する場合は、拡張により増加する分の入出力処理量を取得する。例えば、
・同期ランダムライト →1,000IOPS増加
・ランダムリード →2,000IOPS増加
・その他のアクセス種別→なし
などの情報を得る。
【0056】
次に、リソース予測部120は、図3に示した例と同様に、I/O特性121を入力として、モデル作成部110により予め作成されている線形モデル112のうちの入出力処理量モデルを利用して、アプリケーションの入出力特性(増加分)に対して必要となるストレージ211のリソース使用量を予測する(S12)。例えば、図2に示したような線形近似された入出力処理量モデルから、
・CPU使用率
・同期ランダムライト(1,000IOPS増加)→10%増加
・ランダムリード(2,000IOPS増加) →15%増加
・ディスクビジー率
・同期ランダムライト(1,000IOPS増加)→5%増加
・ランダムリード(2,000IOPS増加) →10%増加
というような予測値を得る。
【0057】
次に、割当判定部140は、ステップS12で得られたストレージ211のリソース使用量の予測値と、リソース使用状況111から得られる現在の各物理サーバ210のストレージ211のリソースの使用状況とから、対象の仮想サーバ231の割当先とする物理サーバ210(ストレージ211)、もしくは現状の物理サーバ210(ストレージ211)上での拡張可否を判定し、割当情報142として出力する(S13)。例えば、新規に仮想サーバ231を構築する場合、
・ストレージA(211a)に割り当てた場合のリソース使用量
・CPU使用率 →105%
・ディスクビジー率→75%
・ストレージB(211b)に割り当てた場合のリソース使用量
・CPU使用率 →45%
・ディスクビジー率→35%
となり、ストレージA(211a)に割り当てた場合にはCPU使用率が100%を超えてしまうため、まだリソースに余裕があるストレージB(211b)に割り当てるのが適していると判定する。割り当て可能なストレージ211が複数ある場合は、予め定めたルール(例えば、ストレージ211の番号順や、空きリソース量の多い順など)に基づいて割り当てるようにしてもよい。
【0058】
既存の仮想サーバ231を拡張する場合も同様に、例えばストレージA(211a)に割り当てられた仮想サーバA(231a)を対象とする場合、仮想サーバA(231a)上でアプリケーションを拡張すると、上記と同様にストレージA(211a)のCPU使用率が100%を超えてしまうため、ここでの拡張は行えない。従って、リソースに余裕があるストレージB(211b)に仮想サーバA(231a)を移行した後で拡張を行うか、もしくは、リソースに余裕があるストレージ211がない場合には拡張を見送るなどの判定を行う。
【0059】
最後に、ステップS13で得られた割当情報142に基づいて、自動もしくは管理者等による手動により、新規の仮想サーバ231のストレージ211への割当や、既存の仮想サーバ231の拡張などを行う(S14)。以上の処理により、各テナントの仮想サーバ231上で稼働するアプリケーションの入出力特性に応じて仮想サーバ231の配置を最適化することが可能となる。
【0060】
以上に示したように、本発明の実施の形態1であるストレージリソース制御システム100によれば、各仮想サーバ231によるストレージ211のリソースの使用可能量を、仮想化ソフトウェア220が通常有するネットワーク帯域制御機能(帯域制御部221)を用いることで容易に制御する。すなわち、各仮想サーバ231について、物理サーバ210とストレージ211との間のネットワーク212の帯域使用量に帯域制御部221によってキャップを設定することで、間接的に各仮想サーバ231によるストレージ211のリソースの使用可能量を所定の範囲に制御し、他の仮想サーバ231に使用可能量として割り当てられているストレージリソースを侵食しないようにする。これにより、「最低保証型」の性能保証機能を実現することが可能となる。
【0061】
また、モデル作成部110によって作成される入出力処理量モデルと帯域使用量モデルを利用することで、各仮想サーバ231がアプリケーションでの入出力処理のために必要とするストレージ211のリソース使用量に対応したネットワーク212の帯域使用量を予測することができる。予測された帯域使用量の情報を、帯域制御情報132として仮想化ソフトウェア220の帯域制御部221に適用することで、各仮想サーバ231に割り当てられるストレージリソースの使用可能量を、アプリケーションの入出力特性に応じて最適な値に設定することが可能となる。
【0062】
<実施の形態2>
以下では、本発明の実施の形態2であるストレージリソース制御システムを有する情報処理システムについて説明する。
【0063】
[概要]
上述した実施の形態1におけるストレージリソース制御システム100によれば、各仮想サーバ231によるストレージ211のリソースの使用可能量を、仮想化ソフトウェア220のネットワーク帯域制御機能(帯域制御部221)を用いることで容易に制御し、「最低保証型」の性能保証機能を実現することができる。また、このとき、線形モデル112(入出力処理量モデルと帯域使用量モデル)を作成してこれを利用することで、各仮想サーバ231がアプリケーションでの入出力処理のために必要とするストレージ211のリソース使用量(最大使用量)に対応したネットワーク212の帯域使用量を予測することができる。
【0064】
しかしながら、上記の線形モデル112を利用した帯域使用量の予測は、ストレージ211に対する入出力特性(ストレージに対するアクセスパターン)が混在していないアプリケーションを対象としている。仮想サーバ上で稼働するアプリケーションが例えばデータベース管理システム(DBMS(DataBase Management System))である場合、すなわち、仮想サーバが仮想DBサーバである場合は、仮想DBサーバからのストレージに対するアクセスパターンが複数混在することになるため、上記のような線形モデル112を利用してアプリケーション(仮想DBサーバ)に対してストレージリソースの使用量を適切に割り当てて制御することは困難である。
【0065】
図8は、物理サーバ上に仮想DBサーバを構築する際の一般的な構成例について概要を示した図である。例えば、Oracle(登録商標)などを始めとする一般的なDBMSでは、データベースに対する各処理内容を記録してロールフォワードリカバリーを可能とするための作業履歴ログであるREDOログ211−2、過去のREDOログ211−2をアーカイブしておくためのアーカイブ(ARCH)ログ211−3、その他の実データ等(DBデータ211−1)を、ストレージサーバ240上などでそれぞれ異なる論理ボリュームを構成して保持するのが一般的である。
【0066】
また、これらのボリュームに対しては、例えばiSCSIなどを利用したネットワーク上で、仮想DBサーバ231’から1本の(仮想)ネットワークパスを構成してアクセスする。図8の例では、Linux(登録商標)上でOracle VMを利用して、ストレージサーバ240との間の仮想ネットワーク212’を利用する仮想DBサーバを構成した場合の例を示している。
【0067】
仮想DBサーバ231’からのストレージサーバ240上の各ボリュームに対するアクセス特性はそれぞれ異なる場合がある。例えば、仮想DBサーバ231’を利用してDBデータ211−1にアクセスするアプリケーションによる通常処理(OLTP(On-Line Transaction Processing:オンライントランザクション処理))の実行時や、バッチ処理、大量のデータ読み込みを伴うDSS(Decision Support System:意思決定支援システム)処理などの負荷の大きな処理の実行時、さらには仮想DBサーバ231’によるREDOログ211−2のログスイッチ時などで多くのストレージリソースを必要とするボリュームや、使用するリソースの分布状況は異なってくる。
【0068】
これにより、例えば、バッチ処理やログスイッチなど、一時的に負荷の大きな処理が実行される場合、これらの処理がストレージリソースを大量に使用するため、通常処理(OLTP)やこれに伴うREDOログ211−2への書き込み処理などが影響を受けてスループットが低下してしまう場合などが生じる。この状況は、本実施の形態のようなマルチテナント環境ではテナント間での処理が重複する場合があることにより一層顕著となる。
【0069】
そこで、本実施の形態であるストレージリソース制御システムを有する情報処理システムでは、上記のようなアクセスパターンが異なる3種類のボリュームに対して、各テナントの仮想DBサーバ231’からそれぞれ独立したネットワークパスを介してアクセスするように仮想ネットワークを構成する。
【0070】
図5は、本実施の形態における物理サーバ上に仮想DBサーバを構築する際の構成例について概要を示した図である。図5の例では、上述したように、仮想DBサーバ231’がストレージサーバ240上の各ボリュームに対して、VLAN(Virtual LAN)などの仮想ネットワーク212’によって分離された異なるセグメントのネットワークパスを介してアクセスするように構成されている。なお、仮想ネットワークによる独立したネットワークパスの構成手段は特に限定されず、対象のプラットフォームなどに応じて公知の仮想ネットワーク技術を適宜利用することができる。
【0071】
この仮想ネットワーク212’における各仮想ネットワークインタフェース(図5における仮想DBサーバ231’上のvif1.0〜1.2)に対して、実施の形態1と同様に、仮想化ソフトウェア220のネットワーク帯域制御機能を利用してアクセス先のボリュームの特性に合わせた帯域使用量の制御を行う。これにより、仮想DBサーバ231’によるストレージサーバ240のリソース使用量についても「最低保証型」の性能保証を行うことを可能とし、他のテナントでの処理により受ける影響を低減する。また、各ボリュームに対するアクセスの特性に応じてストレージリソースを効率的に配分することで、データベース処理におけるスループットの向上および安定化を図ることを可能とする。
【0072】
[システム構成]
図6は、本実施の形態であるストレージリソース制御システムおよびこれを有する情報処理システムの構成例の概要について示した図である。図6において、情報処理システム1のリソースプール200における各物理サーバ210およびストレージサーバ240は、上述した図5と同様の構成を有する。すなわち、仮想DBサーバ231’がストレージサーバ240上の各ボリュームに対して、仮想ネットワーク212’によって構成された異なるセグメントのネットワークパスを介してアクセスするように構成されている。この仮想ネットワーク212’に対して、仮想化ソフトウェア220の帯域制御部221よるネットワーク帯域制御機能を利用してアクセス先のボリュームの特性に合わせた帯域使用量の制御を行う。
【0073】
一方、ストレージリソース制御システム100’は、実施の形態1における図1のストレージリソース制御システム100の帯域決定部130に相当するものとして、ソフトウェアプログラムとして実装される帯域決定部130’を有する。なお、帯域決定部130’を、実施の形態1の図1におけるストレージリソース制御システム100に組み込んで実装することで、実施の形態1におけるストレージリソースの性能保証を行うための帯域制御情報132の出力機能と、本実施の形態における仮想DBサーバ231’によるストレージリソースの使用量に対する制御を行うための帯域制御情報132’の出力機能とを併存させてもよい。
【0074】
帯域決定部130’は、仮想化ソフトウェア220の帯域制御部221に設定する、仮想DBサーバ231’における仮想ネットワーク212’のパス毎についての帯域上限値を決定し、帯域制御情報132’として出力する。ここでは例えば、図示しない運用管理システム等を利用して予め測定された、各物理サーバ210の(物理)ネットワーク212およびストレージサーバ240についてのパフォーマンスに係る測定情報であるDB測定情報111’を入力とし、所定の計算方法に従って、各ボリュームにアクセスするための仮想ネットワークパス毎の帯域使用量の上限値を決定して出力する。DB測定情報111’については、例えば、仮想化ソフトウェア220の帯域制御部221による帯域制御を行わない状態で、対象の仮想DBサーバ231’上で通常処理(OLTP)を行うことでデータベースに負荷をかけて測定する。
【0075】
なお、DB測定情報111’に含まれる情報としては、例えば、REDOログ211−2の平均レコードサイズ、TPS(Transaction Per Second:1秒あたりのトランザクション処理件数)数、REDOログ211−2のログスイッチの平均時間間隔、(物理)ネットワーク212におけるインバウンド/アウトバウンドの帯域最大使用量などが挙げられる。
【0076】
帯域決定部130’によって出力される帯域制御情報132’の内容を、実施の形態1の場合と同様に、ストレージリソース制御システム100’による自動もしくは管理者等による手動によって仮想化ソフトウェア220の帯域制御部221に適用し、帯域制御部221により仮想DBサーバ231’における仮想ネットワーク212’の各ネットワークパスの帯域使用量を制御する。これにより、間接的に仮想DBサーバ231’によるストレージサーバ240のリソース使用量を所定の範囲内に制御することができる。さらに、各ボリュームに対するアクセスの特性に応じてストレージリソースを効率的に配分することで、後述するように仮想DBサーバ231’におけるスループットの安定化と向上を図ることができる。
【0077】
[ボリューム毎の帯域上限値の決定方法]
以下では、ストレージサーバ240上のボリューム毎に、DB測定情報111’に基づいてどのように帯域上限値を決定するかについて説明する。まず、DBデータ211−1へのアクセス用ネットワークパス(図5におけるvif1.0)についてのインバウンド(リード)の帯域上限値については、通常処理(OLTP)におけるDBデータ211−1からのデータの読み込み量に対応した帯域とすることで、DBデータ211−1に対する読み込みを絞る。すなわち、バッチ処理やDSS処理など一時的に大きな負荷がかかる処理についてもDBデータ211−1へのアクセスの際のリソース使用量を通常処理並みに制限する。これにより、これらの処理におけるストレージリソースの浪費を抑制することができる。
【0078】
なお、バッチ処理やDSS処理におけるストレージリソースの使用量が制限されることで、これらの処理に要する時間が長くなってしまう場合もあり得るが、元来これらの処理は通常処理(OLTP)に比べて処理時間に対する要求は緩やかであるため多くの場合問題とはならない。
【0079】
また、REDOログ211−2へのアクセス用ネットワークパス(図5におけるvif1.1)についてのアウトバウンド(ライト)の帯域上限値についても、同様に、通常処理(OLTP)におけるREDOログ211−2へのログの書き込み量に対応する帯域使用量とすることで、REDOログ211−2に対する書き込みを絞る。すなわち、バッチ処理やDSS処理についてもREDOログ211−2へのログ書き込みの際のリソース使用量を通常処理並みに制限する。
【0080】
通常処理(OLTP)は、処理が常時継続して行われるため、REDOログ211−2に対して常時一定量のログの書き込みが行われる。一方、バッチ処理やDSS処理については、処理量が多いことからログの書き込みも通常処理(OLTP)に比べて多くなる。従って、これらの処理によるREDOログ211−2へのログの書き込みの際のリソース使用量を通常処理並みに制限することで、ストレージリソースの浪費を抑制することができる。なお、バッチ処理やDSS処理におけるストレージリソースの使用量が制限されることで、これらの処理に要する時間が長くなってしまう場合もあり得るが、上記のDBデータ211−1の場合と同様に多くの場合問題とはならない。
【0081】
また、ARCHログ211−3へのアクセス用ネットワークパス(図5におけるvif1.2)についてのアウトバウンドの帯域上限値については、これを絞ることで通常処理(OLTP)によるARCHログ211−3への書き込みを平滑化する。これにより、ARCHログ211−3への書き込み処理がREDOログ211−2へのログの書き込みを妨げることを抑止し、結果として通常処理(OLTP)のスループットの安定化および向上を図ることができる。
【0082】
通常、ARCHログ211−3へのアーカイブログの書き込みは、REDOログ211−2でのログスイッチ発生時などに短時間で多くの書き込みを行うため、その間はストレージリソースを多く消費してしまう。本実施の形態のようなマルチテナント形態のシステムでは、複数テナント(仮想DBサーバ231’)のARCHログ211−3への書き込みが同時に発生することによるレスポンス低下のリスクが、シングルテナント形態の場合と比較して高くなる。そこで、上記のようにストレージリソースの使用量を制限してARCHログ211−3への書き込みを絞り、「短時間の大量書き込み」から「長時間の少量書き込み」に変更することで、上述したレスポンス低下のリスクを回避し、通常処理(OLTP)のスループットの安定化および向上を図る。
【0083】
また、通常処理(OLTP)とバッチ処理やDSS処理とのARCHログ211−3へのアーカイブログの書き込み間隔を比較すると、一般的に、通常処理(OLTP)の方が圧倒的に長い傾向がある。そこで、上記のようにストレージリソースの使用量を制限して、通常処理(OLTP)におけるARCHログ211−3への書き込みの間隔を、書き込み待ちが発生しない程度に長くなるようにすると、必然的にバッチ処理やDSS処理におけるARCHログ211−3への書き込みの際には、アーカイブログの書き込み待ちが発生し、結果としてバッチ処理やDSS処理によるストレージリソースの浪費を抑制することができる。
【0084】
上記のような考え方に基づくREDOログ211−2およびARCHログ211−3へのアクセス用ネットワークパスについての帯域上限値の見積もりは、図5、図6に示したような仮想ネットワーク212’の構成をとることで、図8に示したような従来の構成をとる場合と比較して容易となる。例えば、REDOログ211−2へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値については、DB測定情報111’から得られる情報に基づいて、単に、
REDOログ211−2の平均レコードサイズ × TPS数 …(1)
で見積もることができる。
【0085】
また、REDOログ211−2のログスイッチ等に伴って古いREDOログ211−2のログデータをARCHログ211−3へ書き込む際に必要となるストレージリソースを制御するための、REDOログ211−2へのアクセス用ネットワークパスについてのインバウンドの帯域上限値、およびARCHログ211−3へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値については、
REDOログ211−2のファイルサイズ
÷ REDOログ211−2のログスイッチの平均時間間隔 …(2)
で見積もることができる。これにより、通常処理(OLTP)におけるARCHログ211−3への書き込みの間隔を、書き込み待ちが発生しない程度に長くすることができる。
【0086】
なお、式(2)において、REDOログ211−2のファイルサイズは、仮想DBサーバ231’上のDBMSでの設計情報や構成情報から取得することができる。また、ARCHログ211−3へのアクセス用ネットワークパスについてのインバウンドについてはデータ量がごく僅かであるため帯域上限値の設定は特に不要である。
【0087】
上記のような見積もりによってREDOログ211−2やARCHログ211−3へのアクセス用ネットワークパスについて帯域上限値を設定してストレージサーバ240のリソース使用量を制限したにもかかわらず、ログ書き込みがストレージリソースを浪費し、通常処理(OLTP)の処理を妨げる場合は、これらのボリュームを別のストレージ筐体に配置することで、通常処理(OLTP)の性能を保証することができる。
【0088】
[処理フロー]
以下では、ストレージリソース制御システム100’による処理の流れについて説明する。図7は、仮想化ソフトウェア220の帯域制御部221に対して仮想ネットワーク212’のネットワークパス毎に適用するための帯域制御情報132’を出力する処理の流れの例について概要を示したフローチャートである。
【0089】
まず、図示しない運用管理システム等を利用して、予め、仮想化ソフトウェア220の帯域制御部221による仮想ネットワーク212’の帯域制御を行わない状態でデータベースに負荷をかけ、各物理サーバ210の(物理)ネットワーク212およびストレージサーバ240についてのパフォーマンスを測定してDB測定情報111’を取得する(S21)。次に、DB測定情報111’の値に基づいて、REDOログ211−2へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値を決定する(S22)。ここでは、上記の式(1)に基づいて見積もられた値を帯域上限値とする。
【0090】
次に、DB測定情報111’の値、および仮想DBサーバ231’上のDBMSでの設計情報等に基づいて、REDOログ211−2へのアクセス用ネットワークパスについてのインバウンドの帯域上限値、およびARCHログ211−3へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値を決定する(S23)。ここでは、上記の式(2)に基づいて見積もられた値を帯域上限値とする。ARCHログ211−3へのアクセス用ネットワークパスについてのインバウンドの帯域上限値については、上記の通り特に設定は不要であるが、適当な値を設定するようにしてもよい。
【0091】
次に、DB測定情報111’の値、およびステップS22で決定したREDOログ211−2へのアクセス用ネットワークパスについてのアウトバウンドの帯域上限値に基づいて、DBデータ211−1へのアクセス用ネットワークパスについてのインバウンドおよびアウトバウンドの帯域上限値を決定する(S24)。ここで、例えば、インバウンドの帯域上限値については、DB測定情報111’から得られる(物理)ネットワーク212におけるインバウンドの帯域最大使用量をそのまま帯域上限値として決定する。また、アウトバウンドの帯域上限値については、
(物理)ネットワーク212におけるアウトバウンドの帯域最大使用量
− REDOログ211−2へのアクセス用ネットワークパスに
ついてのアウトバウンドの帯域上限値 …(3)
で見積もることができる。
【0092】
最後に、ステップS22〜S24で得られた各ボリュームへのアクセス用ネットワークパスについてのインバウンド/アウトバウンドの帯域上限値を帯域制御情報132’として出力する(S25)。これを仮想化ソフトウェア220の帯域制御部221に適用することで、対象の仮想DBサーバ231’が使用するストレージサーバ240のリソース使用量の上限を間接的に制御し、他の仮想DBサーバ231’が必要とするリソース使用量を侵食しないようにすることができる。また、各仮想DBサーバ231’におけるストレージリソースの使用をボリューム毎に効率化し、スループットの安定化と向上を実現することができる。
【0093】
なお、図7の処理フローにおいて、例えばステップS22〜S24の処理順序はこれに限られるものではなく、各帯域上限値の決定順序は適宜変更することができる。また、実施の形態1の場合と同様に、上記の一連の処理を定期的に自動で実行することで、リソースプール200の各ストレージサーバ240において、負荷状況に合わせて各仮想DBサーバ231’のリソース使用量を動的に最適化して割り当てることも可能となる。
【0094】
なお、本実施の形態では、DB測定情報111’におけるTPS数や、REDOログ211−2の平均レコードサイズ、ログスイッチの平均時間間隔といったパフォーマンス情報を測定して得ることで、対象の仮想DBサーバ231’に対して必要なストレージリソースを割り当てることを想定している。一方、例えば、新規の仮想DBサーバ231’を構築する場合や、既存の仮想DBサーバ231’を拡張する場合には、アプリケーション等の分析によって得られるこれらのパフォーマンス情報の予測値を利用することで、必要となるストレージリソース(仮想ネットワーク212’の帯域上限値)の予測値を得ることができる。これにより、実施の形態1における割当判定部140での処理(図4における割当情報142の出力処理)と同様の処理により、仮想DBサーバ231’をいずれの物理サーバ210(ストレージサーバ240)に割り当てるかを判定することができる。
【0095】
以上に示したように、本発明の実施の形態2であるストレージリソース制御システム100’によれば、リソースプール200において、仮想DBサーバ231’が使用するストレージサーバ240上の各ボリュームについて、仮想ネットワーク212’によってそれぞれ独立したネットワークパスを介してアクセスするよう仮想DBサーバ231’を構成する。これにより、実施の形態1と同様に、各仮想DBサーバ231’によるストレージサーバ240(ストレージサーバ240上の各ボリューム)のリソースの使用可能量を、仮想化ソフトウェア220が通常有するネットワーク帯域制御機能(帯域制御部221)を用いて容易に制御し、他の仮想DBサーバ231’に使用可能量として割り当てられているストレージリソースを侵食しないようにすることで、「最低保証型」の性能保証機能を実現することが可能となる。
【0096】
また、仮想DBサーバ231’によるストレージサーバ240上の各ボリュームに対するアクセスパターンに応じてストレージリソースをボリューム毎に効率的に配分することで、例えば、バッチ処理やDSS処理など一時的に大きな負荷がかかる処理が複数テナントで同時に実行されるような場合でも、これらの処理によるストレージリソースの浪費を抑制し、通常処理(OLTP)の性能を劣化させることなく実行することが可能となり、仮想DBサーバ231’におけるスループットの安定化と向上を図ることができる。
【0097】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【産業上の利用可能性】
【0098】
本発明は、ストレージ機器のリソース使用量について最低保証型の性能保証を行うよう制御するためのストレージリソース制御システムおよびストレージリソース制御プログラムならびにストレージリソース制御方法に利用可能である。
【符号の説明】
【0099】
1…情報処理システム、
100、100’…ストレージリソース制御システム、
110…モデル作成部、111…リソース使用状況、111’…DB測定情報、112…線形モデル、
120…リソース予測部、121…I/O特性、122…予測使用量、
130、130’…帯域決定部、131…設定ポリシー、132、132’…帯域制御情報、
140…割当判定部、142…割当情報、
200…リソースプール、
210(210a、210b)…物理サーバ(物理サーバA、物理サーバB)、211(211a、211b)…ストレージ(ストレージA、ストレージB)、211−1…DBデータ、211−2…REDOログ、211−3…ARCHログ、212(212a、212b)…ネットワーク(ネットワークA、ネットワークB)、212’…仮想ネットワーク、220(220a、220b)…仮想化ソフトウェア(仮想化ソフトウェアA、仮想化ソフトウェアB)、221(221a、221b)…帯域制御部(帯域制御部A、帯域制御部B)、231(231a1、231a2、231b1)…仮想サーバ(テナントa1用仮想サーバ、テナントa2用仮想サーバ、テナントb1用仮想サーバ)、231’…仮想DBサーバ、240…ストレージサーバ。

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

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate


【公開番号】特開2012−133630(P2012−133630A)
【公開日】平成24年7月12日(2012.7.12)
【国際特許分類】
【出願番号】特願2010−285941(P2010−285941)
【出願日】平成22年12月22日(2010.12.22)
【出願人】(000155469)株式会社野村総合研究所 (1,067)
【Fターム(参考)】