IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日立ヴァンタラ株式会社の特許一覧

特許7549433リソース構成見積もりシステムおよびリソース構成見積もり方法
<>
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図1
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図2
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図3
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図4A
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図4B
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図5
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図6
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図7
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図8
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図9A
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図9B
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図10
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図11
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図12
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図13
  • 特許-リソース構成見積もりシステムおよびリソース構成見積もり方法 図14
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-09-03
(45)【発行日】2024-09-11
(54)【発明の名称】リソース構成見積もりシステムおよびリソース構成見積もり方法
(51)【国際特許分類】
   G06Q 50/10 20120101AFI20240904BHJP
【FI】
G06Q50/10
【請求項の数】 12
(21)【出願番号】P 2020143644
(22)【出願日】2020-08-27
(65)【公開番号】P2022038919
(43)【公開日】2022-03-10
【審査請求日】2023-02-24
(73)【特許権者】
【識別番号】524132520
【氏名又は名称】日立ヴァンタラ株式会社
(74)【代理人】
【識別番号】110002365
【氏名又は名称】弁理士法人サンネクスト国際特許事務所
(72)【発明者】
【氏名】寺山 充実
【審査官】松田 岳士
(56)【参考文献】
【文献】特開2016-035642(JP,A)
【文献】特開2014-219936(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
移行元の第一の計算機システムにおける第一のリソースを、移行先の第二の計算機システムへ移行させた場合における第二のリソースのリソース構成を見積るリソース構成見積もりシステムであって、
前記第一のリソースから収集された該第一のリソース性能データに基づいて、該第一のリソースにおける負荷の発生確率が従う移行元負荷モデルの母分布を比定により推定する移行元負荷モデル推定部と、
前記移行元負荷モデルに基づいて、前記第二のリソースの負荷を表す移行先負荷モデルを推定する移行先負荷モデル推定部と、
前記第一のリソースの性能要件と、前記移行先負荷モデル推定部によって推定された前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルを判別し、適合すると判別した前記移行先負荷モデルに基づいて前記リソース構成の設計値を決定する移行先構成設計部と、を有し、
前記移行先構成設計部は、
前記第一のリソースに基づいて判別されたサービスレベルに応じた設計補正値を、サービスレベル毎の設計補正値を管理する定義情報を参照して取得し、取得した該設計補正値を用いて、前記性能要件に適合する前記移行先負荷モデルに基づく前記リソース構成の設計値を前記リソース構成の設計の余裕度を小さくする方向へ補正する
ことを特徴とするリソース構成見積もりシステム。
【請求項2】
前記第一のリソースおよび前記第二のリソースは、ストレージリソースであり、
前記移行先負荷モデル推定部は、
前記第二のリソースのボリューム種別毎に前記移行先負荷モデルを推定し、
前記移行先構成設計部は、
前記性能要件と、前記移行先負荷モデル推定部によって推定された前記ボリューム種別毎の前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルのボリューム種別を判別し、
前記性能要件に適合する前記移行先負荷モデルのボリューム種別についての前記移行先負荷モデルに基づく前記リソース構成の設計値を、前記設計補正値を用いて修正する
ことを特徴とする請求項1に記載のリソース構成見積もりシステム。
【請求項3】
前記移行元負荷モデルは、前記第一のリソースの負荷を確率モデルで表し、
前記移行先負荷モデルは、前記第二のリソースの負荷を待ち行列で表す
ことを特徴とする請求項1に記載のリソース構成見積もりシステム。
【請求項4】
前記確率モデルは、ポアソン分布、指数分布、または正規分布のカーネルである
ことを特徴とする請求項3に記載のリソース構成見積もりシステム。
【請求項5】
前記移行先負荷モデル推定部は、
前記待ち行列の平均待ち長さと、前記待ち行列の長さの分散から定められる特定パーセンタイルである基準待ち長さとを推定し、
前記移行先構成設計部は、
前記リソース構成の設計値を決定する際、
前記第二の計算機システムのストレージリソースの課金方法が、最大性能型の場合には前記平均待ち長さを最大IO設計値とし、バケット型の場合には前記平均待ち長さをベースライン性能、前記基準待ち長さをバースト時性能とする
ことを特徴とする請求項3に記載のリソース構成見積もりシステム。
【請求項6】
前記第一の計算機システムはオンプレミス環境上に構築され、
前記第二の計算機システムはパブリッククラウド環境上に構築されている
ことを特徴とする請求項1に記載のリソース構成見積もりシステム。
【請求項7】
前記移行元負荷モデル推定部は、
評価期間における前記第一のリソースの性能の実績データに基づいて前記移行元負荷モデルを推定し、推定した前記移行元負荷モデルに関するモデル化誤差が所定範囲内であるか否かを評価し、前記モデル化誤差が前記所定範囲外である場合に前記評価期間を修正し、修正した前記評価期間における前記第一のリソースの性能の実績データに基づいて前記移行元負荷モデルを再推定する
ことを特徴とする請求項1に記載のリソース構成見積もりシステム。
【請求項8】
前記移行先構成設計部は、
前記第一のリソースの入出力の特性に応じて、前記モデル化誤差を評価するための前記所定範囲を調整する
ことを特徴とする請求項7に記載のリソース構成見積もりシステム。
【請求項9】
前記移行先構成設計部は、
前記第一のリソースと類似の構成を持つ過去のリソースの移行履歴に基づく設計実績値と前記設計値との誤差が所定値以上の場合に、前記設計補正値を再設定し、再設定した前記設計補正値を用いて前記設計値を再補正する
ことを特徴とする請求項1に記載のリソース構成見積もりシステム。
【請求項10】
前記移行先構成設計部は、
前記設計補正値の再設定では、前記移行履歴と前記サービスレベルとに基づいて前記設計補正値を増加または減少させる
ことを特徴とする請求項9に記載のリソース構成見積もりシステム。
【請求項11】
前記移行先構成設計部は、
前記第一のリソースの入出力の特性に応じて、前記誤差を評価するための前記所定値を調整する
ことを特徴とする請求項9に記載のリソース構成見積もりシステム。
【請求項12】
移行元の第一の計算機システムにおける第一のリソースを、移行先の第二の計算機システムへ移行させた場合における第二のリソースのリソース構成を見積るリソース構成見積もりシステムが行うリソース構成見積もり方法であって、
前記第一のリソースから収集された該第一のリソース性能データに基づいて、該第一のリソースにおける負荷の発生確率が従う移行元負荷モデルの母分布を比定により推定する移行元負荷モデル推定ステップと、
前記移行元負荷モデルに基づいて、前記第二のリソースの負荷を表す移行先負荷モデルを推定する移行先負荷モデル推定ステップと、
前記第一のリソースの性能要件と、前記移行先負荷モデル推定ステップによって推定された前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルを判別し、適合すると判別した前記移行先負荷モデルに基づいて前記リソース構成の設計値を決定する移行先構成設計ステップと、を有し、
前記移行先構成設計ステップでは、
前記第一のリソースに基づいて判別されたサービスレベルに応じた設計補正値を、サービスレベル毎の設計補正値を管理する定義情報を参照して取得し、取得した該設計補正値を用いて、前記性能要件に適合する前記移行先負荷モデルに基づく前記リソース構成の設計値を前記リソース構成の設計の余裕度を小さくする方向へ補正する
ことを特徴とするリソース構成見積もり方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、リソース構成見積もりシステムおよびリソース構成見積もり方法に関する。
【背景技術】
【0002】
情報システム分野において、クラウドコンピューティングと呼ばれる利用形態が普及し、企業や自治体などの事業者が自身でシステムを保有することなく情報サービスを提供することができるようになった。いわゆるパブリッククラウドは機能要件や非機能要件に合わせて様々なサービスを提供しており、ユーザがそれらを自在に選択し組み合わせることで、保有型のシステムよりも安価に所望のサービスを構築することが可能となっている。
【0003】
一方で、保守性やセキュリティ保護、サービス品質など主にコスト以外の観点から、従来主流であったように情報システムを自ら維持し続ける場合(オンプレミス)もある。よってオンプレミス、プライベートクラウド、パブリッククラウドのいずれか一つの環境に全ての役割を担わせるのではなく、個々のサービスに応じて使い分けることが重要となっている。
【0004】
このような使い分けの形態によって、ユーザ環境は、マルチクラウドあるいはハイブリッドクラウドと呼ばれる。ユーザ側でもシステムのライフサイクルや事業をとりまく状況により需要が変化するほか、各クラウドが提供する機能性や仕様が様々に異なることから、ユーザは、システムに対するリソース構成を監視し、定期的に見直す必要に迫られる。
【0005】
例えば、オンプレミス環境にあるサーバやストレージなどのITリソースをパブリッククラウドへ移行する際には、移行元において生じていた負荷を十分処理できるよう移行先の構成を設計しなければならない。特にストレージリソースは構築後に構成を変更することが比較的難しいために、様々なサイジング手法やその自動化技術が提案されている。
【0006】
このような従来技術として、例えば次の特許文献1では、機械学習により移行元および移行先における負荷の特性を抽出し、リソース構成のパターンとして管理することで精度の高いサイジング技術を開示している。
【先行技術文献】
【特許文献】
【0007】
【文献】米国特許第98647492号明細書
【発明の概要】
【発明が解決しようとする課題】
【0008】
特許文献1に開示の従来技術によれば、個々の負荷情報をパターン化することができるために、ある程度の不測の負荷が観測される場合でも近似のパターンを検出し、サイジングを完了することができる。また、サイジングを行おうとする利用者が特にストレージリソースの管理や構成設計に関わる知識に通じていない場合であっても適切な移行先構成を見積もることができる。さらには、対象のシステムにおける構成や設定値に差異があってもサイジングにかかるモデルを自動的に構築、修正できることから、環境の変化に頑強で信頼性の高いサイジング結果を得ることができる。
【0009】
しかしながら、サイジングの精度を高めるためには多様かつ多数の構成パターンおよび負荷のデータを収集し、事前に学習処理を行っておく必要がある。これは当然に長時間、大量の負荷データや構成情報を必要とし、処理量の大きい手法であり、負荷データや構成情報に未知な変数が多い場合には適用が難しい。
【0010】
また、サイジングの結果として得られた構成が、実際に移行を完了した後で期待通りの負荷特性にならなかった場合、各設計項目の関係が自明ではないため、構成をどのように修正すれば有効であるか不明である。
【0011】
ここでITリソースの管理においては、サイジングの誤差や、予期しない負荷の上昇、障害発生時の備えとして、余分のリソース量を考慮するのが通例である。これらの安全マージンを含むため、実用上のリソース量は真に利用されるリソース量よりも大きく見積もられている場合が多く、特にサービス品質の低下が事業成果に大きく影響する基幹システムにおいてその傾向が顕著である。
【0012】
特にストレージリソースにおいては、ファイルシステムなどの構造によってデータ配置が抽象化されるため、容量の拡張が容易である一方で、縮小が困難である。この時、安全マージンを大きく設定するやり方では、後で実使用状況に合わせて容量を縮小することが難しいため、サイジング時のマージンの設定方法によってはリソース利用コストが過大となる恐れがある。
【0013】
本発明は以上の点に鑑み、ITリソースの移行において、移行先のリソースをより適切にサイジングすることを目的とする。
【課題を解決するための手段】
【0014】
本発明は、上記課題を解決するために、移行元の第一の計算機システムにおける第一のリソースを、移行先の第二の計算機システムへ移行させた場合における第二のリソースのリソース構成を見積るリソース構成見積もりシステムは、前記第一のリソースの負荷を表す移行元負荷モデルを推定する移行元負荷モデル推定部と、前記移行元負荷モデルに基づいて、前記第二のリソースの負荷を表す移行先負荷モデルを推定する移行先負荷モデル推定部と、前記第一のリソースの性能要件と、前記移行先負荷モデル推定部によって推定された前記移行先負荷モデルとを比較して、前記性能要件に適合する前記移行先負荷モデルを判別し、適合すると判別した前記移行先負荷モデルに基づいて前記リソース構成の設計値を決定する移行先構成設計部と、を有し、前記移行先構成設計部は、前記性能要件に適合する前記移行先負荷モデルに基づく前記リソース構成の設計値を、要求されるサービスレベルに応じた設計補正値を用いて、前記リソース構成の設計の余裕度を小さくする方向へ補正することを特徴とする。
【発明の効果】
【0015】
本発明によれば、ITリソースの移行において、移行先のリソースをより適切にサイジングできる。
【図面の簡単な説明】
【0016】
図1】実施例1における計算機システムの全体構成の概要を示す図。
図2】実施例1における第一の計算機システムの詳細構成を示す図。
図3】実施例1における第二の計算機システムの詳細構成を示す図。
図4A】実施例1における第一の計算機システムの管理コンピュータのプログラム構成を示す図。
図4B】実施例1における第二の計算機システムの管理コンピュータのプログラム構成を示す図。
図5】実施例1の第一の計算機システムにおけるグレード定義情報の例を示す図。
図6】実施例1の第一の計算機システムにおけるボリューム性能情報の例を示す図。
図7】実施例1におけるインスタンス構成情報の例を示す図。
図8】実施例1の第二の計算機システムにおけるボリューム種別情報の例を示す図。
図9A】実施例1の第二の計算機システムにおけるバケット型課金方法の概念を示す図。
図9B】実施例1の第二の計算機システムにおけるバケット型課金方法の概念を示す図。
図10】実施例1の第二の計算機システムにおけるボリューム性能情報の例を示す図。
図11】実施例1におけるストレージ構成見積もりプログラムの概要を示す図。
図12】実施例1におけるストレージ構成見積もり処理を示すフローチャート。
図13】実施例2における処理フローを示す。
図14】管理コンピュータ等の各装置を実現するコンピュータ5000のハードウェア図である。
【発明を実施するための形態】
【0017】
以下、図面を参照して本発明の実施例を説明する。実施例は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、種々の他の形態でも実施することが可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。
【0018】
各種情報の例として、「テーブル」、「リスト」、「キュー」等の表現にて説明することがあるが、各種情報はこれら以外のデータ構造で表現されてもよい。例えば、「XXテーブル」、「XXリスト」、「XXキュー」等の各種情報は、「XX情報」としてもよい。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ID」、「番号」等の表現を用いるが、これらについては互いに置換が可能である。各種情報は、揮発性または不揮発性の記憶装置の記憶領域に格納される。
【0019】
同一あるいは同様の機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。また、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。
【0020】
実施例において、プログラムを実行して行う処理について説明する場合がある。計算機は、プロセッサ(CPU(Central Processing Unit)、GPU(Graphics Processing Unit)等)によりプログラムを実行し、記憶資源(メモリ等)やインタフェースデバイス(通信ポート等)を用いながら、プログラムで定められた処理を行う。そのため、プログラムを実行して行う処理の主体を、「XXX部」としてもよいし、プロセッサとしてもよい。
【0021】
同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であればよく、特定の処理を行う専用回路を含んでいてもよい。ここで、専用回路とは、例えばFPGA(Field Programmable Gate Array)やASIC(Application Specific Integrated Circuit)、CPLD(Complex Programmable Logic Device)等である。
【0022】
プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、実施例において、2以上のプログラムが1つのプログラムとして実現されてもよいし、1つのプログラムが2以上のプログラムとして実現されてもよい。
【0023】
実施例において、第一の計算機システムから第二の計算機システムへの移行対象をストレージリソースとして説明するが、これに限らず、サーバやネットワーク機器といったITリソース一般を移行対象とすることができる。
【実施例1】
【0024】
実施例1では、オンプレミス環境で稼働するストレージリソースに対して、パブリッククラウドへ移行した際の構成を見積もるシステムが提供される。
【0025】
オンプレミス環境とパブリッククラウド環境を併用することで、ITシステムに対するサービス需要や、セキュリティ、性能などの要件に合わせて最適な構成でインフラストラクチャを運用することができる。
【0026】
しかしながら、各環境の利用状況が異なっていたり、利用時間の長さや構成の大きさ、利用可能なクラウドサービスの種類が多数存在したりするといった事情によって、オンプレミス、クラウドのいずれがより費用面で適するかは一定でない。そこで、実際に適材適所の構築を行い、要件を満たしながらコストを削減するには、システムの稼働状況に合わせて適切な構成を見積もる手段が必須となる。
【0027】
<実施例1のシステム構成>
図1は、実施例1における計算機システムSの全体構成の概要を示す図である。計算機システムSは、第一の計算機システム1Sおよび第二の計算機システム2Sを含んで構成される。第一の計算機システム1Sはオンプレミス環境である。第一の計算機システム1Sは、エンドユーザに対して情報サービスを提供するユーザ自身によって保有され、運用管理されるシステムである。
【0028】
第二の計算機システム2Sはパブリッククラウド環境である。第二の計算機システム2Sは、クラウド事業者によってユーザに対して従量課金等によりインフラストラクチャが提供されるシステムである。
【0029】
第一の計算機システム1Sを所有するユーザは、第一の計算機システム1Sに関わる構成情報や性能情報を占有して管理することができる。一方、このユーザは、第二の計算機システム2Sを不特定多数の第三者と物理的に共有している。このため第二の計算機システム2Sにおいて、ユーザの管理が及ぶ範囲は限られる。
【0030】
第二の計算機システム2Sを運用するクラウド事業者は、一定のサービス規約のもとで、ユーザに対し、第二の計算機システム2Sに関わる利用状況を限定的に提供し、また構成変更の権限を限定的に付与する。
【0031】
またクラウド環境においては、必要分量のリソースのみを迅速に構築する機能が具備されており、時々の需要に合わせて、必要リソース量を従量課金により利用できる。オンプレミス環境では、ユーザが装置およびリソースを常に保有する形態で構築されることから、需要の変化に合わせてクラウド環境を利用することで、ユーザはサービスの提供に適したリソース量の決定のみに集中でき、システムの運用管理や利用にかかるコストを圧縮できる場合がある。
【0032】
第一の計算機システム1Sは、情報サービスを提供するユーザが自身のデータセンタ150に構築されるITインフラストラクチャであり、計算リソースを提供する複数のサーバ装置10、ストレージリソースを提供する複数のストレージ装置100、およびそれらを相互に接続する内部ネットワーク50を含んで構成される。情報サービスを提供する各アプリケーションは、サーバ装置10で稼働し、必要に応じてストレージ装置100にデータを格納する。
【0033】
第一の計算機システム1Sにはシステム運用管理基盤300が設置され、ユーザのうち特にインフラストラクチャ管理者によって各装置の構成が管理される。また第一の計算機システム1Sはネットワーク161を介して、広域ネットワーク160に接続される。図1では第一の計算機システム1Sの構成要素を模式的に示しており、各装置が同じ計算機システムを構成する目的で複数のデータセンタ150に渡って構築されていてもよい。
【0034】
第二の計算機システム2Sは、データセンタ250に構築されるITインフラストラクチャであり、複数のサーバ装置20、複数のストレージ装置200、およびそれらを相互に接続する内部ネットワーク70を含んで構成される。各アプリケーションがサーバ装置20で稼働し、必要に応じてストレージ装置200にデータを格納する。
【0035】
第二の計算機システム2Sにはシステム運用管理基盤400が設置され、ユーザの要求に応じて各装置の構成を管理する。また第二の計算機システム2Sはネットワーク162を介して、広域ネットワーク160に接続される。図1では第二の計算機システム2Sの構成要素を模式的に示しており、各装置が同じ計算機システムを構成する目的で複数のデータセンタ250に渡って構築されていてもよい。
【0036】
情報サービスの消費者であるエンドユーザのクライアントコンピュータ163は、広域ネットワーク160を介して、第一の計算機システム1Sまたは第二の計算機システム2S上のアプリケーションと接続されている。クライアントコンピュータ163が各サーバ装置10またはサーバ装置20と通信することで、第一の計算機システム1Sのユーザが構築した情報サービスの提供を受けることができる。エンドユーザは通信先のサーバ装置が第一の計算機システム1Sの一部であるか、あるいは第二の計算機システム2Sの一部であるかを特に区別する必要はない。
【0037】
図2は、実施例1における第一の計算機システム1Sの詳細構成を示す図である。第一の計算機システム1Sは、1つ以上のサーバ装置10、1つ以上のストレージ装置100、管理コンピュータ301、およびそれらを相互に接続するネットワーク161を含んで構成される。ネットワーク161は複数のネットワークスイッチから構成され、必要に応じて管理コンピュータ301がそれらネットワークスイッチの構成を管理していてもよい。
【0038】
また、アプリケーションがデータの送受信を行うために、サーバ装置10とストレージ装置100との間に専用の内部ネットワーク50が構築される。内部ネットワーク50は大容量のデータを効率的に転送するためにファイバチャネルなど特定のプロトコルを利用するものであってもよい。内部ネットワーク50は、ネットワークスイッチやアダプタを適宜用いて構築される。
【0039】
サーバ装置10はプロセッサや揮発性メモリなどの一般的な計算機アーキテクチャを備え、情報サービスを提供するために必要なアプリケーション14を稼働させる。アプリケーション14の動作に必要なリソースはサーバ装置10上に直接的に稼働するOS(Operating System)13か、物理リソースを柔軟に利用するために仮想化ソフトウェア11により実現される仮想マシン12をさらに導入した形態によって構築される。
【0040】
アプリケーション14は、サーバ装置上のネットワークインタフェース15を介してネットワーク161に接続される。また、アプリケーション14が利用する不揮発性のストレージ領域は、ストレージ装置100により論理ボリューム16として提供される。アプリケーション14は、論理ボリューム16を直接的に利用するか、あるいは仮想化ソフトウェア11の機能によりさらに仮想ディスク17として利用する形態をとる。仮想ディスク17は専ら、論理ボリューム16に設定されたファイルシステム上のファイルとして構成される。
【0041】
ストレージ装置100は、サーバ装置10に不揮発性のストレージ領域を提供するための装置であり、複数のサーバ装置10から同時にデータの送受信を受け付ける。本実施例において、ストレージ装置100はストレージ機能を効率的に提供するために共有ストレージコントローラ101を備え、データの送受信やストレージデバイスとの読み書きといった役割が共有ストレージコントローラ101に集約される。
【0042】
共有ストレージコントローラ101は、プロセッサや揮発性メモリといった一般的な計算機アーキテクチャと同様の構成を持ち、HBA(Host Bus Adapter)52やNIC(Network Interface Card)105によりそれぞれ内部ネットワーク50やネットワーク161に接続される。
【0043】
ストレージ装置100は多数のHDD(Hard Disk Drive)やSSD(Solid State Drive)といったストレージデバイス102を備えるが、これらはそのままストレージ領域としてサーバ装置10に提供されるのではなく、構成管理がしやすいようさらに論理的な構造が定義される。
【0044】
より具体的には、複数のストレージデバイスをRAID(Redundant Arrays of Independent Disks)グループ103として束ね、さらにストレージプール104を構築して論理ボリューム116を構成する。ストレージプール104は各論理ボリューム116に対して容量を動的に割り当てるための構造であり、複数の論理ボリューム116が単一のストレージプール104を共有して容量を融通しあえる他、複数のRAIDグループ103に分散させてデータを格納する機能を実現する。
【0045】
IO(Input/Output)性能やレイテンシ、帯域などの性能は、ストレージデバイス102の種別により異なっており、同一のストレージプール104を構成する各RAIDグループ103の容量比率によりストレージ領域を階層化することができる。ストレージデバイス102の種別によって性能や容量単価が異なっており、ユーザが実現したい情報サービスの要件に合わせて利用できるよう、複数のストレージ階層を用意する。これらストレージ階層が後述するグレードと関連づけられる。
【0046】
ストレージプール104から割り当てられる論理ボリューム116は、サーバ装置10から論理ボリューム16として認識される。データ読み書きの応答性を高める目的で、共有ストレージコントローラ101はさらに揮発性メモリをキャッシュ領域として利用する場合がある。さらに、管理コンピュータ301から要求を受けて構成を変更したり、性能情報を取得させたりといった管理機能を実現するために、共有ストレージコントローラ101は管理インタフェースを備える。
【0047】
管理コンピュータ301は、サーバ装置10やストレージ装置100の構成を管理するためのプログラム群を稼働させ、システム運用管理基盤300の機能を実現する。それらのプログラム群を総称して管理プログラムと呼び、構成は動作の詳しい説明と合わせて後述する。システム運用管理基盤300の機能を構成するために、必要であれば管理コンピュータ301は、複数のコンピュータに分かれて構築されていてもよい。
【0048】
図3は、実施例1における第二の計算機システム2Sの詳細構成を示す図である。第二の計算機システム2Sは、1つ以上のサーバ装置20、1つ以上のストレージ装置200、管理コンピュータ401、およびそれらを相互に接続するネットワーク162を含んで構成される。ネットワーク162は複数のネットワークスイッチから構成され、必要に応じて管理コンピュータ401がそれらネットワークスイッチの構成を管理していてもよい。
【0049】
また、アプリケーションがデータの送受信を行うためにサーバ装置20とストレージ装置200との間に専用の内部ネットワーク70を構築される。本実施例において、例えばストレージ装置200は、分散ストレージであり、内部ネットワーク70を通じて協調的に動作する。サーバ装置20およびストレージ装置200は物理的には同様の汎用コンピュータであり、各機能を実現するソフトウェアを同一装置上で稼働させてもよいが、ここでは説明のため別途の装置であるものとする。
【0050】
サーバ装置20は、プロセッサや揮発性メモリなどの一般的な計算機アーキテクチャを備え、情報サービスを提供するために必要なアプリケーション24を稼働させる。アプリケーション24の動作に必要なリソースは、サーバ装置20上で直接的に稼働するOS23か、物理リソースを柔軟に利用するために仮想化ソフトウェア21により実現される仮想マシン22をさらに導入した形態によって構築される。アプリケーション24は、サーバ装置20上のネットワークインタフェース25を介してネットワーク162に接続される。また、アプリケーション24が利用する不揮発性のストレージ領域は、ストレージ装置200の分散ストレージが構築する論理ボリューム26として提供される。
【0051】
ストレージ装置200は、サーバ装置20に不揮発性のストレージ領域を提供するための装置であり、分散ストレージとして複数のストレージ装置200が協調的に動作し複数のサーバ装置10からデータ送受信を受け付ける。ストレージ装置200は、プロセッサや揮発性メモリといった一般的な計算機アーキテクチャと同様の構成を有し、分散ストレージコントローラ201と呼ばれるソフトウェアによりストレージ機能を実現する。
【0052】
ストレージ装置200ではOS213が動作し、各物理リソースを制御する。分散ストレージコントローラ201は、ストレージ装置200に内蔵されるストレージデバイス202をそのままサーバ装置10に提供するのではなく、構成管理がしやすいようさらに論理的な構造を定義する。より具体的には、RAIDグループ203として各ストレージデバイス202を束ねてファイルシステムを定義し、分散ストレージコントローラ201が利用するストレージコンテナ204を構築する。
【0053】
ストレージコンテナ204は、ファイルシステム上のファイルまたはディレクトリとして実現される。ストレージ領域をサーバ装置20に提供する際には複数のストレージコンテナ204から容量を割り当て、論理ボリューム216を構成する。分散ストレージコントローラ201が構成する論理ボリューム216は、サーバ装置20からは論理ボリューム26として認識され、個々のストレージ装置200やネットワークに障害が発生した場合にも機能を継続できるよう各ストレージ装置200で構成情報が同期される。
【0054】
このように、ストレージコンテナ204は元々物理的にはストレージ装置200に内蔵されるストレージデバイス202であるが、ストレージデバイス202のHDDの回転数や帯域、SSDの集積度などが様々に異なっており、ストレージコンテナ204の割り当て方によって性能と容量の関係が異なる論理ボリューム216が構成できる。
【0055】
ここでは、特性の異なる論理ボリューム216を第一の計算機システム1Sにおけるグレードと同様に、複数に区別して提供することとし、これをボリューム種別と呼ぶ。管理コンピュータ401からの要求を受けて構成が変更できるよう、ストレージ装置200はさらにネットワークインタフェース205によってネットワーク162に接続され、必要な管理インタフェースを稼働させる。
【0056】
第二の計算機システム2Sにおけるストレージ装置200では、ストレージコンテナ204を介して容量を割り当てる仕組みによって、論理ボリューム216のIO性能を容易に調整できるという利点がある。これはシステムが継続的に稼働することにより、論理ボリューム216が消費するストレージ容量が増加したときに、容易に容量を追加できるという利点も併せ持つ。
【0057】
一方で、論理ボリューム216に格納されたデータは、論理アドレス上に分散していることから、後になって容量を縮減することが難しい。容量を削減するには、サーバ装置20側で管理されるファイルシステムの利用情報を調べて、使用されていないアドレスの部分のみを削除、または使用されているアドレスの部分のみを退避する必要がある。このため通常は、第二の計算機システム2Sの運用者は、容量の縮減を認めていない。
【0058】
後述するように、論理ボリュームの課金額は容量によって決まる場合が多く、利用開始当初に大きめに容量を見積もっておき利用を継続した後で容量を削減するという手段が困難であることから、見積もり時点の課金額が長期間を通じて強く影響すると言える。
【0059】
管理コンピュータ401は、サーバ装置20やストレージ装置200の構成を管理するためのプログラム群を稼働させ、システム運用管理基盤400の機能を実現する。それらのプログラム群を総称して管理プログラムと呼び、構成は動作の詳しい説明と合わせて後述する。システム運用管理基盤400の機能を構成するために必要であれば、管理コンピュータ401は、複数のコンピュータに分散して構築されていてもよい。
【0060】
図4Aは、実施例1における第一の計算機システム1Sの管理コンピュータ301のプログラム構成を示す図である。管理コンピュータ301では、第一の計算機システム1Sにおける各装置の構成を管理する目的の管理プログラムとして、ストレージ構成見積もりプログラム311、ストレージ性能分析プログラム312、ストレージ性能管理プログラム313、ストレージ構成管理プログラム315、およびインスタンス構成管理プログラム316が稼働する。さらに、管理コンピュータ301では、ストレージ性能管理プログラム313が利用するストレージ性能履歴データベース314が稼働し、取得されたストレージ装置100に関わる性能情報を保管できるようにしておく。
【0061】
ストレージ構成見積もりプログラム311の処理の説明は後述する。
【0062】
ストレージ性能分析プログラム312は、論理ボリューム16または仮想ディスク17毎の性能を分析する。ストレージ性能分析プログラム312による分析結果は、性能情報として、ストレージ性能管理プログラム313により管理される。
【0063】
ストレージ性能管理プログラム313は、ストレージ装置100におけるボリューム性能を管理し、要求に応じて他の管理プログラムに提供する。ストレージ性能管理プログラム313がストレージ性能履歴データベース314を用いて管理する性能情報とは、例えば図6に示す形式のボリューム性能情報321であり、ストレージ装置100の共有ストレージコントローラ101から取得され、ストレージ性能分析プログラム312によって分析された分析結果である。
【0064】
ストレージ構成管理プログラム315は、ストレージ装置100の論理構成および物理構成を管理する。より具体的には、ストレージ構成管理プログラム315は、各論理ボリューム116、ストレージプール104、RAIDグループの割り当て関係や、ネットワークインタフェース52と論理ボリューム116の接続関係、論理ボリューム116に対するキャッシュメモリの割り当てなどの構成を管理する。
【0065】
またストレージ構成管理プログラム315は、他の管理プログラムと連携してストレージ装置100の管理に必要な機能および情報を提供する。また論理ボリューム116の予約容量や実使用容量、ストレージプール104の性能および価格を左右するストレージデバイス102の割り当てメディア比率などの構成情報も、ストレージ構成管理プログラム315により管理される。
【0066】
前述の通り、ストレージ装置100に構成されるストレージ階層は、最終的にユーザに提供される性能および価格と関係しており、例えば図5に示す形式のグレード定義情報320として管理される。
【0067】
ストレージ装置100では、各グレード定義情報320における性能を満足するようにストレージプール104に紐づけるRAIDグループ103を調整することにより実現される。グレードはユーザとのサービス条件を定める目安であり、ここではユーザが自ら性能要件に合致するグレードを選択し、ボリュームに割り当てた容量に比例した料金を支払う。ただし、論理ボリューム116がどのようなファイルシステムを定義され、仮想ディスク17などの用途に利用されているかなどについてはユーザの管掌であるので、ストレージ構成管理プログラム315は、サーバ装置10側で制御される構成を管理しない。
【0068】
インスタンス構成管理プログラム316は、サーバ装置10上にアプリケーション14を稼働させるための計算リソースに関わる構成情報を管理する。ここでの構成情報は、例えば図7に示す形式のインスタンス構成情報322である。、第二の計算機システム2Sにおける、サーバ装置20上にアプリケーション24を稼働させるための計算リソースに関わるインスタンスの構成情報も同様の形式である。
【0069】
図4Bは、実施例1における第二の計算機システム2Sの管理コンピュータ401のプログラム構成を示す図である。管理コンピュータ401では、第二の計算機システム2Sにおける各装置の構成を管理する目的の管理プログラムとして、ストレージリモート管理インタフェースプログラム411、ストレージ性能分析プログラム412、ストレージ性能管理プログラム413、ストレージ構成管理プログラム415、およびインスタンス構成管理プログラム416が稼働する。さらに、管理コンピュータ401では、ストレージ性能管理プログラム413が利用するストレージ性能履歴データベース414が稼働し、取得されたストレージ装置200に関わる性能情報を保管できるようにしておく。
【0070】
管理コンピュータ401が第一の計算機システム1Sにおける管理コンピュータ301のプログラムの構成と異なる点は、ストレージリモート管理インタフェースプログラム411を備える点である。これは、第二の計算機システム2Sが第一の計算機システム1Sの管理者およびユーザとは異なる他者(クラウド事業者)によって運用され、さらに複数の第三者とも共同利用されることから、適正な管理機能および情報のみを遠隔に提供するという事情による。
【0071】
ストレージリモート管理インタフェースプログラム411は、同じく管理コンピュータ401上に稼働するストレージ性能管理プログラム413などの管理プログラムと連携して機能するが、第二の計算機システム2Sの外部に提供可能な機能および情報はユーザ権限に応じて全体の一部に制御される。より具体的には、例えばインスタンス構成管理プログラム416が管理するインスタンス構成情報322において、特定のユーザまたはユーザグループが参照・変更可能な情報は当該インスタンスにおける所有者のみに制御する、などの機能を有する。
【0072】
第二の計算機システム2Sにおいては、インフラストラクチャの運用者が複数のユーザに対して計算機システムを分配し、従量課金により利用させる形態をとる。すなわち、第一の計算機システム1Sのユーザを含む不特定多数のユーザが第二の計算機システム2Sを共有して利用しており、第一の計算機システム1Sのユーザはそれら他のユーザの利用状況を知ることができない。
【0073】
第二の計算機システム2Sにおける課金方法の主要な例として、最大性能型とバケット型の二通りを想定する。運用者のサービス定義によって、その他の項目として転送帯域(単位時間あたりの転送データ量)や下り転送量、およびスナップショットなどの有償オプションをさらに課金対象として用意する場合があるが、例えば転送帯域は、以降に述べるIOPSに平均IOサイズを乗じたものであり従属の量である。よって、本実施例においては、特に性能要件において重要な役割を担う設計事項に着目して説明する。
【0074】
また、IOPSや転送帯域はそれぞれ、トランザクションやスループットの用語でも呼称されるが、いずれも同義のものであり本実施例に述べる原理は一様に適用可能である。これらの課金方法は、ボリューム種別毎に定義され、例えば図8に示すような形式のボリューム種別情報420がストレージ構成管理プログラム415において管理される。
【0075】
ここでいう最大性能型は、ユーザが設定した最大IOPSとストレージ容量によって課金額が決定される方法である。各論理ボリューム216には、ストレージ容量に応じて提供可能なIOPSが決定される。ユーザは当該IOPS以下の値を最大IOPSに設定することで課金額が決定される。例えば、当該ストレージリソースの利用状況、ひいては当該システムの利用状況を熟知しているユーザによって、繁忙期のみに最大IOPSを高く設定することで、通常の課金額を削減する効果が得られる。
【0076】
一方で、バケット型は、ユーザが設定したストレージ容量と所与のバースト可能IO量によって課金額が決定される。図9Aおよび図9Bにバケット型課金方法の概念図を示す。これは、各論理ボリューム216に対してベースライン性能605と呼ばれる値(IO量)を想定し、ベースライン性能605を超えるIOに対してはバースト可能IOと呼ばれる一定値を越えない範囲でIO処理を保証する方法である。
【0077】
ベースライン性能605はストレージ容量に比例して定義され、単位時間あたりの流入IO601のうちベースライン性能605を越えたものがバーストIOとして蓄積される様子から(リーキー)バケット600に例えられる。流入IO601がベースライン性能605に達しない間(符号604)はバケット600に蓄積されず、ベースライン性能605を超えた場合にバケット600に蓄積され始める(符号606)。バースト可能IOに達した場合には以降のIO要求が失敗または遅延させられる。IO要求がベースライン性能605を下回れば、バケット600に蓄積されたIOが流出IO602の相当分減少し(符号607)、次のバーストIOを受け入れられる余地が増える。
【0078】
バースト可能IOに対するその時の蓄積IO量は、その比率を用いて、バケットバランス603として表すことができる。理想的には要求IO量に対して常にバケットバランス603が1未満であるように設計される。
【0079】
バケット型においては、所定の量まではバーストIOに課金しない課金方法をとっているものが多く、その場合はベースライン性能605を踏まえて容量を設計することで、一定のバーストIOが想定されるリソースであってもベースライン性能605分の価格で利用することが可能となる。
【0080】
いずれの課金方式においても、ストレージ性能管理プログラム413が管理するボリューム性能情報421(図10)に基づいて論理ボリューム26の利用状況が測定され、それに応じた利用料金が算定される。
【0081】
IO負荷は、実際にはIOPSのみではなく、IOブロック長さやシーケンシャル/ランダム比率、読み書き比率、キャッシュ利用率などのIO特性や、直前の利用状況、同一のコントローラに対する他のサーバからの利用状況などの、多数の要因により一定ではない。
【0082】
しかしながら、特に第二の計算機システム2Sでは、運用者とユーザが異なっていたり、複数のユーザが同じ装置を共有していたり、かつ公正にリソースを分配する必要があったりといった第二の計算機システム2Sに特有な利用形態を想定するため、ごく少数の設計パラメータによってIO性能を設計させる仕様を採用している。ここで述べる課金方法が、専ら容量とIOPSという二つの設計値に強く依存しているのは、他の設計パラメータが支配的でないから除外できるという意図ではなく、少数に限定せざるを得ない事情による。
【0083】
いずれの課金方法であっても、当該ストレージ領域が移行の前後で同じアプリケーションおよび近似のサーバ装置構成から利用されると想定すると、性能要件において、移行元で生じていたもとのIO要求を受け付けられるよう移行先IO性能を設計する必要がある。上述のようにIO性能は容量と関係するよう定義されており、当該IO性能を満たすように容量を考慮しなければならない。このとき、定常的に生じるIO量と、ごく短期的に高騰した場合のIO量と、の二つのIO性能指標が重要となる。ボリューム種別によって課金方法が異なるため、容量や積算したIO量が一定であっても、時間当たりのIO特性が異なっていれば最も安価な課金方法が時々により異なる可能性がある。
【0084】
<見積もりプログラムの概要>
図11は、実施例1におけるストレージ構成見積もりプログラム311の概要を示す図である。本実施例における見積もりとは、第一の計算機システム1S、特にストレージリソースの指定を処理要求とし、第二の計算機システム2Sへ当該リソースを移行した場合の当該計算機システムにおける課金額、および容量やIO性能などの設計値を処理結果として算出することを言う。特に記載しない限り他の用語と組み合わされる場合も同じ意味であり、例えば見積もり方法や見積もりプログラムとは、それぞれ見積もりを行う方法や見積もりに関わる処理を実現するプログラムのことを指す。
【0085】
ここでは第一の計算機システム1Sから第二の計算機システム2Sへのストレージリソースの移行を考え、便宜上、本実施例における第一の計算機システム1Sを移行元、第二の計算機システム2Sを移行先と呼ぶことがある。
【0086】
ストレージ構成見積もりプログラム311は、主に移行元負荷モデル推定部350、移行先負荷モデル推定部352、および移行先構成設計部353を含んで構成される。その他、ストレージ構成見積もりプログラム311は、必要に応じて、例えば移行元負荷モデル推定部350の処理に必要な性能データをストレージ性能分析プログラム312から取得し加工する目的で性能情報集計部351を、移行先負荷モデル推定部352や移行先構成設計部353における処理に必要とする移行先の情報を管理する移行先仕様管理部354を、移行先構成設計部353の処理に必要な補正値を管理する補正値管理部355を、それぞれの機能別に備える。
【0087】
ストレージ構成見積もりプログラム311は概ね、移行元における負荷をモデル化し、同じく移行先の負荷を表すモデルに当てはめた上で、性能要件ほかの要件を満たすように設計値を定め、複数存在するボリューム種別毎に同様の設計を繰り返す、という処理を実現する。
【0088】
移行元負荷モデル推定部350は、移行元である第一の計算機システム1Sにおいて、指定されたストレージリソースにおける負荷(IOPS)を統計的にモデル化するものである。より具体的には、例えばIOPSの発生確率が指数分布やポアソン分布に従うとして最尤法により平均や分散などのパラメータを比定するものや、同様に正規分布のカーネル密度推定により特定のカーネル関数の重ね合わせと比定するものがある。
【0089】
移行元負荷モデルの母分布を推定する手法は、反復アルゴリズムや機械学習による。移行元負荷モデルは論理ボリューム16または仮想ディスク17毎に作成され、ストレージ性能分析プログラム312から負荷モデル作成対象であるリソース部分の性能データを取得し、性能情報集計部351の集約処理を経たもの、すなわち所定の評価区間において集計やリサンプリング、欠損値処理を施したものを入力(学習データ)とする。
【0090】
移行元負荷モデル推定部350において同定されたパラメータとして、例えば発生確率を与える母分布の平均や分散を、以降の移行先負荷モデル推定部352の処理に用いる。移行元負荷の非定常性(時間軸に対して移動平均が変動する性質)が強い場合には、母分布推定を定常成分のみに限定し、非定常なトレンドや周期成分を別途回帰問題としてさらにモデル化してもよい。
【0091】
また要求される見積もりが将来の区間を含む場合には、非定常成分を加味して上記の母分布における平均をシフトする。また、カーネル密度推定などによって、移行元負荷モデルが複数の確率分布に従う混合分布であると想定される場合には、各母分布(カーネル関数)をそれぞれ推定し、移行先負荷モデルもそれぞれ別に考える。この場合は、見積もり結果を各移行先負荷モデルの出力による重み付き線形結合で表現する。
【0092】
移行先負荷モデル推定部352は、移行先である第二の計算機システム2Sにおいて、あるボリューム種別について定められた仕様をもとに、論理ボリューム26に生じうる負荷をモデル化するものである。ここでは、課金方法のIO性能における要件をもとに、待ち行列モデルを用いることを考える。このとき、待ち行列において待ちに入る到着過程が移行元負荷モデル推定部350が表す負荷、待ちから出ていく時間当たり処理能力が移行先論理ボリュームにおける性能(ベースライン性能635)、待ち状態にある量がバケット型課金方法においてバケットに蓄積されたIO量と比定できる。
【0093】
最も単純に、移行元負荷が指数分布やポアソン分布でモデル化できる場合、移行先の負荷は待ち行列の平均や分散などのパラメータを用いて解析的に同定できる。したがって、この場合は移行先負荷の推定に機械学習や他の反復的手法によるモデル同定が不要である点において、推定にかかる処理量を低減することができる。
【0094】
より具体的には、移行先負荷を待ち行列としてモデル化した場合、バケットに蓄積されるIOの平均値が待ち行列の平均待ち長さに相当し、また蓄積されるIOが増減する度合は待ち行列の分散により表現される。このとき、待ち行列の分散から定められる特定のパーセンタイルを、バケットバランスの最大ではないが十分大きい値であるとみなして、基準待ち長さと呼ぶこととする。
【0095】
ただし、特に移行先のストレージ装置200が不特定多数のサーバ装置20から負荷を受けている状況では、ストレージ構成見積もりプログラム311で対象とするストレージリソースの他にも同一の論理ボリューム216の性能に影響するものが存在しており、また前述のように設計値が少数に限られており、それらの他者の影響を検知するための性能指標が十分に得られない可能性が残ることから、第二の計算機システム2Sの運用者が公称する仕様が厳密に保証されるとは限らない。
【0096】
移行先構成設計部353は、移行先負荷モデル推定部352において同定されたパラメータに基づいて、補正値管理部355やストレージ構成管理プログラム315の情報により所定の補正を加えた上で、特定のボリューム種別における容量およびIO性能の設計を行う。原則として、最大性能型の課金方法においては基準待ち長さが最大IO設計値に相当し、バケット型では平均待ち長さがベースライン性能、基準待ち長さがバースト時性能に相当するが、ストレージ容量の縮減が容易でないという第二の計算機システム2Sの特性に鑑みて、これらの値を補正する。
【0097】
具体的には、移行先負荷モデル推定部352が出力する各パラメータに対し、グレード毎に定義した設計補正値を係数として乗じたものを性能要件に基づく設計値とする。このとき、設計補正値は、補正前後のリソース量比率を与える正の数値である。設計補正値はストレージ構成管理プログラム315が管理するグレード定義情報320を参照し、見積もり処理のなかでは補正値管理部355において管理される。グレードはユーザが期待する性能と価格の優先度が反映されたものであるから、より性能を重視するグレードには性能要件上の同定パラメータに近い設計値を、より価格を重視するグレードには同定パラメータに強く下方修正を施した(比較して小さくなるよう変更した)設計値を性能要件上の結果として採用する。
【0098】
これにより、価格を重視するグレードを移行する場合には、性能が不足する恐れはあるが課金額を小さく見積もった結果が得られる。仮にそのような低課金額の見積もり結果を経て、実際に移行された後に性能が不足する事態が生じても、移行後の第二の計算機システム2Sにおける、容量の追加により不足分のIO性能を容易に補うことができる。移行先構成設計部353は、その他、ストレージ構成管理プログラム315から得た各論理ボリューム116の容量(予約または実使用容量)と、性能要件による容量設計値とを比較してより大きい値を最終的な設計値とし、双方の条件をともに満たすよう調整する。
【0099】
移行先構成設計部353は、その他の設計事項についても検証し、ボリューム種別によって機能要件が合致しない場合、例えば移行元の論理ボリューム16または仮想ディスク17がOS起動用のストレージ領域である場合に移行先ボリューム種別がそれらをサポートしない場合など、には移行先として不適当であると判断する。また、最終的な処理結果としてはコスト最適である移行先構成を示すことを目的とするが、ユーザの判断材料として多角的な評価が必要な場合に備え、課金額以外の構成も併せて処理結果とする。
【0100】
本実施例においては、移行先の情報として、移行の実績に関わる情報、例えば過去に同様のストレージ移行が実際に行われた際にIO性能がどのように変化したか、といった履歴を含まない。このとき、移行先の情報を提供する移行先仕様管理部354は、第二の計算機システム2Sの運用者によって公開されている課金方法についての仕様などの事前情報のみを扱っており、例えば第二の計算機システム2Sに関する稼働状況についての情報が全く得られていない場合においても、本実施例に述べる見積もり方法が実現可能であることが示唆される。
【0101】
<実施例1のストレージ構成見積もり処理>
図12は、実施例1におけるストレージ構成見積もり処理を示すフローチャートである。以降の処理は、主に管理コンピュータ301上のストレージ構成見積もりプログラム311において実行される。
【0102】
ステップ(以下ステップを“S”と記載する)700では、ストレージ構成見積もりプログラム311は、ユーザによる移行対象のインスタンスまたはストレージリソースの指定を受け付けることで処理フローを開始する。移行先である第二の計算機システム2Sにおけるリソースが潤沢に提供されていることを踏まえると、移行対象が複数であった場合は少なくとも本処理フローを繰り返し適用することで複数の移行対象について同様に見積もり可能である。またS700において、ユーザは、見積もり結果のうち最大効果のもののみを取り出すか否かなど、見積もり処理に関する要求を合わせて行ってもよい。
【0103】
S701において、ストレージ構成見積もりプログラム311は、S700で受け付けた移行処理要求で移行対象に指定されたインスタンスまたはストレージリソースを特定する。S701では、ストレージ構成見積もりプログラム311は、指定されたインスタンスまたはストレージリソースについて、対象となる論理ボリューム116を判別し、グレードや使用容量などの構成、および性能情報を取得するために必要な識別子(ボリュームID)を合わせて判別する。S701が終了すると、ストレージ構成見積もりプログラム311は、移行元負荷モデル推定S702(S703~S705)および補正値判定S711へ処理を移す。移行元負荷モデル推定S702は、ストレージ構成見積もりプログラム311の移行元負荷モデル推定部350によって実行される。
【0104】
S703では、移行元負荷モデル推定部350は、S701において判別された識別子を用いて、同じくS701で判別された対象となる論理ボリューム116の性能情報を、ストレージ性能管理プログラム313から取得する。ストレージ構成見積もりプログラム311内の性能情報集計部351は、ストレージ性能分析プログラム312から取得された性能情報に対して集約処理を実施する。
【0105】
図11に示すように、性能情報の集約処理では、所定の評価区間において、主にIOPSの時間変化についてのデータが、移行元負荷モデル推定に適するよう加工される。所定の評価区間は、既定のものを用いてもよいし、S700のリソース指定時にユーザによって都度指定されてもよい。所定の評価区間は、少なくとも移行元環境においてある程度の使用実績があり、かつ高負荷を含む期間であることが望ましい。
【0106】
S704では、移行元負荷モデル推定部350は、移行元負荷モデルとして適切なモデルを選択する。S704では、例えば過去に同様のストレージリソースの見積もりが行われた場合には、過去の見積もり時と同一のモデルを選ぶ。あるいは見積もり処理に関わる処理時間が許容すれば、複数のモデルを用いて実際に評価を行い、最もモデル化誤差を小さくするものを選べばよい。
【0107】
S705では、移行元負荷モデル推定部350は、S704にて選択されたモデルについて移行元負荷モデルのパラメータを評価する。前述の通り、最も簡便には単一のポアソン分布などの母分布を想定した場合、後段の移行先負荷モデル推定S706の入力となる平均到着率を推定する。S705が終了すると、ストレージ構成見積もりプログラム311は、移行先負荷モデル推定S706(S707~S709)へ処理を移す。移行先負荷モデル推定S706は、ストレージ構成見積もりプログラム311の移行先負荷モデル推定部352によって実行される。移行先負荷モデル推定S706では、ボリューム種別毎に負荷の評価を行う。
【0108】
S707では、移行先負荷モデル推定部352は、移行先として想定される全てのボリューム種別について、未評価のボリューム種別の中から1つ選択する。S708では、移行先負荷モデル推定部352は、移行先のボリューム種別をS707で選択されたボリューム種別とした場合の移行先負荷モデルのパラメータを評価する。移行先負荷モデルの離脱速度や最大待ち容量を定める仕様は、移行先仕様管理部354において管理される。移行元負荷モデル推定S702において移行元の負荷を到着過程としてモデル化できれば、移行先の負荷を待ち行列とモデル化でき、S708の移行先パラメータの評価において待ち行列の平均待ち長さや分散を評価できる。
【0109】
S709では、移行先として想定される全てのボリューム種別のうち移行先パラメータが未評価である残りボリューム種別があるか否かを判定し、残りボリューム種別ある場合(S709Yes)にステップS707に処理を移し、残りボリューム種別ない場合(S709No)にステップS710に処理を移す。
【0110】
S710では、移行先構成設計部353は、S707で負荷を評価したボリューム種別のうち、移行先のIO負荷およびその他の要件に適合するボリューム種別を判別する。上述したように、S710は、移行先構成設計部353が、移行対象として指定されたストレージリソースの構成をストレージ構成管理プログラム315から取得し、当該ボリューム種別の仕様と比較することにより実現できる。例えば移行元における当該論理ボリューム116の使用容量が、当該ボリューム種別が提供可能な容量の範囲を逸脱している場合には適合しないものとして除外する。
【0111】
一方で、S711では、ストレージ構成見積もりプログラム311は、S701において判別されたグレードに基づいて補正値を決定し、補正値管理部355に保存する。S712では、移行先構成設計部353は、S701で適合すると判定されたボリュームについての移行先負荷モデルに基づいて、第二の計算機システム2Sにおける移行先のストレージリソースのリソース構成を設計すると共に、この設計に関する設計値に、S711において決定された設計補正値を乗じて補正する。設計値は、移行先での課金額に直接的に関係する容量やIO性能などである。
【0112】
S713では、移行先構成設計部353は、最終見積もり結果として提示する移行後のリソースの設計値や、課金額を最終決定する。S714では、移行先構成設計部353は、S713で決定した最終的な設計値や、最終的な設計値の算出基礎である補正前の設計値、補正前の設計値に乗じた設計補正値などを、ユーザに対して表示したり、ユーザが使用する別の管理プログラムに転送したりし、ストレージ構成見積もり処理を終了する。あるいはS714では、ユーザが処理開始時に指定した要求に応じて、最小の課金額のリソース構成の設計値のみを結果として提示したり、性能値の設計余裕が最大のリソース構成の設計値のみを結果として提示したりしてもよい。
【0113】
本実施例によれば、例えばオンプレミス環境を想定した第一の計算機システム1Sからパブリッククラウド環境を想定した第二の計算機システム2Sへとストレージリソースを移行する際に、事前に構成を見積もる機能が提供される。移行先の構成の詳細や利用状況が自明でない場合であっても、主要な設計値を導出することができ、サイジングに必要な処理量を削減することができる。また、移行元の利用条件に応じてリソースの見積もり量を補正し、ストレージの利用コストを抑制することができる。
【実施例2】
【0114】
本実施例では、オンプレミス環境で稼働するストレージリソースをパブリッククラウドへ移行した際に構成を見積もり、かつ過去に実際に移行を行った後の稼働情報から見積もり方法を修正するシステムが提供される。本実施例は先の実施例1に加えてより正確な見積もり方法を実現するものである。
【0115】
本実施例におけるシステム構成や、管理プログラムの処理内容の多くは実施例1と共通であり、ここでは専ら差異について説明する。
【0116】
前述の通り、本発明の要点の一つは移行先および移行元における負荷のモデル化であるが、見積もり結果と、実際の移行対象のシステムにおける稼働状況には、負荷に差が生じる場合がある。本実施例では、特に移行元負荷モデル推定と移行先負荷モデル推定におけるそれぞれのモデル化誤差に基づいて見積もり方法を改善するための追加の機能を備える。
【0117】
より具体的には、管理プログラムの一つであるストレージ構成見積もりプログラム311において、移行先構成設計部353が移行後の状況を示す移行履歴360をもとに見積もり方法の改善処理を実現する(図11参照)。ここでいう移行履歴360とは、課金額の算定と移行先負荷に関わる実績値であり、移行先のストレージのIOPSの時系列変化や、バケット型であればバケットバランスの時系列データを、設計値と対応を付けた履歴である。移行履歴360は、第二の計算機システム2Sにおいてサポートされる監視機能を利用し、ストレージリモート管理インタフェースプログラム411を介して取得できる。
【0118】
移行元負荷モデル推定部350におけるモデル化誤差は、主に移行元における性能データを集約する手順の良さに関わる。前述の通り、移行元負荷モデルとして特定の確率母分布を想定するが、第一の計算機システム1Sにおいてパラメータ推定に用いる実性能データの区間の取り方や、確率分布の選択によって、実データとモデルとの間に誤差が生じる。本実施例では、性能データの集約方法やモデル選択の調整によって、より精度の高い推定を行う。
【0119】
移行先負荷モデル推定部352におけるモデル化誤差は、主に第二の計算機システム2Sにおける外乱の多寡に関わる。移行先負荷モデルは、第二の計算機システム2Sが公称する性能特性を表現するものであるが、前述の通り、第二の計算機システム2S内における他のユーザの負荷との競合や、性能を左右する他の設計値の影響によって、公称値からの誤差が生じる。本実施例では、ある移行前後に生じる誤差を用いて移行先(第二の計算機システム2S)における外乱的要因を評価し、見積もり方法を調整する。
【0120】
本実施例によれば、数理モデルを用いて移行元負荷および移行先負荷を推定し、負荷やリソースの特性、リソースの構成に支配的に関わる量の関係を表現し、ユーザの挙動や移行元の利用条件に基づいて移行先リソースを設計するので、移行先リソースのサイジングを適切かつ効率的に行うことができる。またマージン(設計余裕)の過大評価によるリソース利用コストの増大を抑制する。
【0121】
また本実施例によれば、移行先の構成の詳細が自明でない場合であっても、主要な設計値(容量やIPOSなど)を導出することができる。また解析的モデルを用いることで負荷推定の処理コストが増大しないよう抑制することにより、移行先リソースのサイジングに必要な処理量を削減する。また移行元リソースの利用条件(要求されるサービスレベルを表すグレード)に応じた設計補正値(図5)を用いて、設計値をリソースの見積もり量を減じる方向へ補正することで、事後に減設が難しいストレージ等の見積もりを、リソースの利用コストを抑制しつつ適切に見積ることができる。
【0122】
<実施例2のストレージ構成見積もり処理>
図13は、実施例2におけるストレージ構成見積もり処理を示すフローチャートである。図13の実施例2のストレージ構成見積もり処理のフローチャートにおいて、図12の実施例1の見積もり処理におけるステップと同一のステップには同一ステップ番号を付与して説明を省略する。
【0123】
実施例2における見積もり処理は、実施例1と同様に、主に管理コンピュータ301上のストレージ構成見積もりプログラム311において実行される。本実施例の見積もり処理では、実施例1と同様に、S700において、トレージ構成見積もりプログラム311は、ユーザによる移行対象のインスタンスまたはストレージリソースの指定を受け付けることで処理フローを開始する。
【0124】
S701が終了すると、ストレージ構成見積もりプログラム311は、移行元負荷モデル推定S702(S703~S705)、補正値判定S711、および移行履歴の取得S711Aへ処理を移す。
【0125】
S702では、実施例1と同様に、S701において判別された識別子を用いて論理ボリューム116の性能情報を取得および集計し(S703)、集計された性能情報に基づいて移行元負荷モデルとして適切なモデルを選択し(S704)し、選択されたモデルについて移行元負荷モデルのパラメータを評価する(S705)。S705では、例えば移行元負荷モデルをポアソン分布などの確率母分布とし、移行先負荷モデルの入力となる平均到着率を推定する。
【0126】
ここで本実施例における性能情報は、実施例1と同じく性能情報集計部351において集約処理が実施される。しかし移行元負荷モデル推定S702の後にS705Aにおいて実行されるモデル化誤差の評価結果によっては、集約処理の期間が修正され得る。
【0127】
特に第一の計算機システム1Sにおけるサーバ装置10の起動時やソフトウェア更新など、アプリケーション14の通常の処理負荷とは大きく異なる状況での性能情報は、モデル化の目的と離反する部分である。よって、対象期間の見直しによって性能情報から除外することでモデル化誤差を解消できる可能性がある。S705Aでモデル化誤差が十分許容できる範囲内であるか否かの判定の結果、S703の性能情報の収集が再実行されることにより、S704におけるモデル選択が修正される場合がある。S705Aでは、移行元負荷モデルの検定による信頼度判定により、モデル化誤差の評価を行う。
【0128】
S705Aにおいてモデル化誤差が十分許容できる所定範囲内と判定された以降は、ストレージ構成見積もりプログラム311は、移行先負荷モデル推定S706(S707、S708、およびS709)に処理を移す。そしてストレージ構成見積もりプログラム311は、S706に続き、S710、S712を実行する。
【0129】
S711では、ストレージ構成見積もりプログラム311は、S701において判別されたグレードに基づいて設計補正値を決定し、補正値管理部355において管理する。S712では、移行先構成設計部353は、S701で適合すると判定されたボリュームについての移行先負荷モデルに基づいて、第二の計算機システム2Sにおける移行先のストレージリソースを設計すると共に、この設計に関する設計値を、S711において決定された設計補正値をもとに修正する。しかしながら、移行先の第二の計算機システム2Sに外乱的要素が含まれる場合には、S711において決定された設計補正値をさらに再設定する必要が生じる。
【0130】
そこで本実施例では、移行先構成設計部353は、S712Aにおいて、当該見積もり対象のボリュームと類似の構成を持つ移行実績の履歴を検索し、移行実績の履歴に基づく移行先リソースの設定実績値と、移行先負荷モデル推定S706の結果との誤差を算出する。移行先構成設計部353は、この誤差が所定値以上の場合には設計補正値を再設定して移行先パラメータを補正するようにS711を再度実施し、誤差が所定値未満の場合にはS713に処理を移す。
【0131】
S712における設計補正値の再設定方法として、例えば外乱が多く、競合する処理負荷が第二の計算機システム2S上で既に稼働していると想定される場合には、設計補正値を増加方向に再設定し、移行先負荷モデル推定S706の出力よりも多くのリソースを確保するようサイジングする。また外乱が小さく、競合する処理負荷が第二の計算機システム2S上で稼働していないと想定される場合には、設計補正値を減少方向に再設定し、モデル出力よりも楽観的に、より少ないリソースの取得にとどめるようサイジングする。
【0132】
より具体的には例えば、設計補正値による補正量が小さく、性能よりも価格が重視されているグレードに対して移行履歴におけるバケットバランスが小さい場合、つまり外乱が生じていないと想定される場合に、サイジング結果がさらに小さくなるよう設計補正値を下方修正する。一方で、外乱が大きいと想定される場合、移行元対象が性能重視のグレードであった場合には、設計補正値による下方修正を緩めて、より多くのリソースを確保するように設計値を見直す。
【0133】
本実施例によれば、実施例1の効果に加えて、過去の同様の構成のリソースの移行履歴に基づいて実際の利用状況に適応させてサイジング結果を補正することで、移行後のリソース構成の見積もりの精度を改善することができる。このとき、見積もり方法において移行元および移行先の挙動を表す数理モデルは、モデルの種類を選ぶ方法やモデル評価のための性能情報の選び方、あるいはパラメータを調整する方法に違いはあっても、解析的モデルを用いる点は変わっておらず、移行元モデルおよび移行先モデルの複雑化を回避できる。これは、例えば機械学習によって構成されるような説明変数の合成量や確率変数を用いるモデルとは異なり、支配的な物理量の関係を表現している点において実際の稼働実績との差異をどのように用いてサイジング結果を修正すべきかを判別できる利点がある。
【0134】
なお実施例1および実施例2において、移行元のストレージリソースの入出力の特性に応じて、S705Aのモデル化誤差を評価するための所定範囲、および/または、S712Aの誤差を評価するための所定値を調整してもよい。例えば計算機システムからネットワークへ情報を送出する下り方向が上り方向よりも課金額が高い場合を考える。この場合に、移行元の第一の計算機システムの1Sのストレージの入出力(Read/Write)のうちReadが多いとき、S705の所定範囲および/またはS712Aの所定値をより小さくして評価精度を高める。一方、Writeが多い場合には、S705の所定範囲および/またはS712Aの所定値をより大きくして評価精度を緩める。このように、ストレージリソースの移行に際し、移行元のストレージリソースのIO特性に応じてS705Aおよび/またはS712の評価精度を調整することで、より厳密にコストを意識して移行先のリソース構成の設計を行うことができる。
【0135】
また上述の実施例1および実施例2では、第一の計算機システム1Sをオンプレミス環境、第二の計算機システム2Sをパブリッククラウド環境として説明した。しかしこれに限らず、第一の計算機システム1Sをパブリッククラウド環境、第二の計算機システム2Sをオンプレミス環境とする場合や、第一の計算機システム1Sおよび第二の計算機システム2Sが共にパブリッククラウド環境である場合でもよい。すなわち第一の計算機システム1Sおよび第二の計算機システム2Sが、オンプレミス環境、パブリッククラウド環境の何れであるかを問わない。
【0136】
<管理コンピュータ301,401を実現するコンピュータ5000>
図14は、管理コンピュータ301,401等の各装置を実現するコンピュータ5000のハードウェア図である。コンピュータ5000では、プロセッサ5100、メモリ5200、ストレージ5300、ネットワークインタフェース5400、入力装置5500、および出力装置5600が、バス5700を介して接続されている。プロセッサ5100は、CPU(Central Processing Unit)等である。メモリ5200は、RAM(Random Access Memory)等である。ストレージ5300は、HDD(Hard Disk Drive)、SSD(Solid State Drive)、媒体読取装置等である。入力装置5500は、キーボード、マウス、タッチパネル等である。出力装置5600は、ディスプレイ等である。
【0137】
コンピュータ5000において、前述の各装置を実現するための各プログラムがストレージ5300から読み出されて、プロセッサ5100及びメモリ5200の協働により実行されることにより、各装置がそれぞれ実現される。あるいは、各装置を実現するための各プログラムは、ネットワークインタフェース5400を介した通信により外部のコンピュータから取得されてもよい。あるいは、各装置を実現するための各プログラムは、可搬型の記録媒体(光学ディスク、半導体記憶媒体等)に記録され、媒体読取装置により読み出されて、プロセッサ5100及びメモリ5200の協働により実行されてもよい。
【0138】
なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明する為に詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置換することも可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。言い換えると、本発明の技術思想の範囲内で矛盾しない限りにおいて、各実施例および変形を組合せることができる。また、実施例における構成および処理の分散および統合を適宜行うことができる。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、各構成を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD(Solid State Drive)等の記録装置、または、集積回路搭載カード、半導体記録媒体、光学式記録媒体等の記録媒体に置くことができる。
【符号の説明】
【0139】
1S:第一の計算機システム、2S:第二の計算機システム、301:管理コンピュータ、311:ストレージ構成見積もりプログラム、350:移行元負荷モデル推定部、351:性能情報集計部、352:移行先負荷モデル推定部、353:移行先構成設計部
図1
図2
図3
図4A
図4B
図5
図6
図7
図8
図9A
図9B
図10
図11
図12
図13
図14