JP2021197010A - 分散型ストレージシステム及びリバランス処理方法 - Google Patents

分散型ストレージシステム及びリバランス処理方法 Download PDF

Info

Publication number
JP2021197010A
JP2021197010A JP2020104544A JP2020104544A JP2021197010A JP 2021197010 A JP2021197010 A JP 2021197010A JP 2020104544 A JP2020104544 A JP 2020104544A JP 2020104544 A JP2020104544 A JP 2020104544A JP 2021197010 A JP2021197010 A JP 2021197010A
Authority
JP
Japan
Prior art keywords
load
volume
node
group
storage system
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
Application number
JP2020104544A
Other languages
English (en)
Inventor
悠貴 坂下
Yuki Sakashita
隆喜 中村
Takayoshi Nakamura
仁志 亀井
Hitoshi Kamei
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2020104544A priority Critical patent/JP2021197010A/ja
Priority to US17/200,417 priority patent/US20210397485A1/en
Publication of JP2021197010A publication Critical patent/JP2021197010A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5083—Techniques for rebalancing the load in a distributed system
    • 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/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/061—Improving I/O performance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0646—Horizontal data movement in storage systems, i.e. moving data in between storage devices or systems
    • G06F3/0647—Migration mechanisms
    • G06F3/0649—Lifecycle management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • 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/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Debugging And Monitoring (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】ボリューム間の組み合わせ最適化計算の計算量を低減する。【解決手段】分散型ストレージシステム１において、ボリュームクラシファイア３００は、複数のボリュームを各ボリュームにおける負荷の変動周期に基づいて複数のグループに分類する。プロセッサ（リソースクラシファイア４００）は、グループ内の同じノード上の複数のボリュームの負荷を時間ごとに合計した合計負荷を算出するとともに、合計負荷のピークに基づいて、グループ負荷を算出する。何れかのノードのプロセッサ（リバランサ５００）は、ノード間でボリュームを移動させるリバランスにおける移動候補のボリュームを移動元ノードから移動先ノードに移動させた場合の移動先ノードのグループ負荷を算出し、当該算出した移動先ノードのグループ負荷に基づいて、リバランスにおける移動するボリュームと移動先ボリュームとを決定し、リバランスを実行する。【選択図】図３

Description

本発明は、プロセッサとメモリとを有しネットワークで互いに接続される複数のノードを備える分散型ストレージシステム、及び分散型ストレージシステムにおけるリバランス処理方法に関する。
近年、ユーザ数や取り扱うデータ量が大きい組織においては、クラウド業者が提供するパブリッククラウドよりも、コスト削減のために、企業や組織が自身でプライベートクラウドを構築して、組織内の各部署にインフラやプラットフォームなどをサービスとして提供する傾向にある。また、プライベートクラウドを構築するストレージのＴＣＯ（Total Cost of Ownership）を削減するために、従来のストレージ専用機ではなく、廉価な汎用サーバ上でストレージ機能をソフトウェアとして実装した分散型ストレージもしくはＳＤＳ（Software Defined Storage）と呼ばれるストレージを用いる事例が増えている。プライベートクラウドでは、様々なアプリケーションが動作し、データごとに異なるレイテンシのＳＬＡ（Service Level Agreement）が存在するため、運用コストを削減して、リソースの使用効率を改善するための自動化技術に注目が集まっている。
上記のプライベートクラウドのように、ストレージ用計算機の数が大きく、様々なワークロードが混在する環境においては、管理者が手動でデータの移動先を決めること無く、自動でデータ（ボリューム）の移動をすることによって各データの要件を満たせる必要があり、各ノード上に各ボリュームをどのように自動で配置するかが課題であった。
上記課題に関連する従来技術として、例えば特許文献１には、ストレージＤＲＳ（Distributed Resource Scheduler）に関する技術が開示されている。特許文献１に開示されたストレージＤＲＳでは、統計情報に基づいて、ノード間の負荷が平準化するようにデータを各ストレージ用計算機に再配置する。また、特許文献２には、仮想ストレージへの負荷等により生じるアクセス性能の低下を改善することを目的としたコンピュータ装置が開示されている。特許文献２に開示されたコンピュータ装置では、キャッシュメモリの利用頻度に応じて、キャッシュメモリのメモリ容量の増減を制御する。
米国特許第８９３５５００号明細書 特開２０１４−１７８９７５号公報
上述したプライベートクラウドのようにストレージ用計算機の数が大きく様々なワークロードが混在する環境においては、データの要件を満たせるように各ノード上で各ボリュームを適切に配置するために、各ノード上の最適なボリューム配置を探索する最適化アルゴリズムが利用される。この代表的な最適化アルゴリズムでは、ボリューム同士の組み合わせ最適化問題を解くことで、最適なボリューム配置を探索する事が可能であるが、その計算量は、ボリューム数をｎとしたとき、Ｏ（ｎ２）で増大することが知られている。そのため、ボリューム数ｎが多い大規模な環境では、ボリューム同士の組み合わせ最適化問題の計算量が非常に大きなものとなり、計算が長期化するためにタイムリーな対処が困難であるという課題があった。また、計算量が非常に大きい最適化問題を解くために、大量の計算用リソースが必要になるという課題もあった。
本発明は以上の点を考慮してなされたもので、ボリューム間の組み合わせ最適化計算の計算量を低減することが可能な分散型ストレージシステム及びリバランス処理方法を提案しようとするものである。
かかる課題を解決するため本発明においては、互いにネットワークで接続され、プロセッサとメモリとを有して、上位システムがデータを入出力する複数のボリュームを提供する複数のノードと、前記ボリュームに入出力されるデータを格納する記憶媒体と、を備えた分散型ストレージシステムにおいて、前記複数のボリュームは、各ボリュームにおける負荷の変動周期に基づいて、複数のグループに分類されており、前記プロセッサは、前記グループ内の同じノード上の複数のボリュームの負荷を時間ごとに合計した合計負荷を算出するとともに、合計負荷のピークに基づいて、グループ負荷を算出し、何れかのノードの前記プロセッサは、前記ノード間でボリュームを移動させるリバランスにおける移動候補のボリュームを移動元ノードから移動先ノードに移動させた場合の前記移動先ノードの前記グループ負荷を算出し、前記算出した移動先ノードのグループ負荷に基づいて、前記リバランスにおける移動するボリュームと移動先ボリュームとを決定し、前記リバランスを実行する、分散型ストレージシステムが提供される。
また、かかる課題を解決するため本発明においては、互いにネットワークで接続され、プロセッサとメモリとを有して、上位システムがデータを入出力する複数のボリュームを提供する複数のノードと、前記ボリュームに入出力されるデータを格納する記憶媒体と、を有する分散型ストレージシステムによるリバランス処理方法において、前記複数のボリュームは、各ボリュームにおける負荷の変動周期に基づいて、複数のグループに分類されており、前記プロセッサが、前記グループ内の同じノード上の複数のボリュームの負荷を時間ごとに合計した合計負荷を算出するとともに、合計負荷のピークに基づいて、グループ負荷を算出し、何れかのノードの前記プロセッサが、前記ノード間でボリュームを移動させるリバランスにおける移動候補のボリュームを移動元ノードから移動先ノードに移動させた場合の前記移動先ノードの前記グループ負荷を算出し、前記算出した移動先ノードのグループ負荷に基づいて、前記リバランスにおける移動するボリュームと移動先ボリュームとを決定し、前記リバランスを実行する、リバランス処理方法が提供される。
本発明によれば、ボリューム間の組み合わせ最適化計算の計算量を低減することができる。
本発明の一実施形態に係る分散型ストレージシステム１の構成例を示すブロック図である。 分散型ストレージシステム１を構成する各ノードのソフトウェアスタックの構成例を示すブロック図である。 ソフトウェアモジュールの分散型ストレージシステム１との関係を示す概要図である。 本実施形態におけるボリュームのグルーピングの概念を説明するための図である。 本実施形態におけるリソースのグルーピングの概念を説明するための図である。 メモリマップの構成例を示すブロック図である。 ノード構成テーブル１２１の構成例を示す図である。 ボリューム負荷テーブル１２２の構成例を示す図である。 ノード負荷テーブル１２３の構成例を示す図である。 グループサイクルテーブル１２４の構成例を示す図である。 ボリュームグループテーブル１２５の構成例を示す図である。 ボリューム配置テーブル１２６の構成例を示す図である。 モニタ頻度テーブル１２７の構成例を示す図である。 リソースキャパシティテーブル１２８の構成例を示す図である。 モニタ２００による処理の処理手順例を示すフローチャートである。 ボリュームクラシファイア３００による処理の処理手順例を示すフローチャートである。 負荷変動の波形の分解を説明するための図である。 リソースクラシファイア４００による処理の処理手順例を示すフローチャートである。 リバランサ５００による処理の処理手順例を示すフローチャートである。 グループ調整処理の処理手順例を示すフローチャートである。 ボリューム再配置処理の処理手順例を示すフローチャートである。
以下、本発明の一実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は、特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。以下の説明では、「テーブル」、「リスト」、「キュー」等の表現にて各種情報を説明する事があるが、各種情報は、これら以外のデータ構造で表現されていても良い。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いるが、これらについてはお互いに置換が可能である。
本実施形態では、分散型ストレージシステムを開示する。まず、この分散型ストレージシステムについて基本的な説明を行う。
分散型ストレージシステムは、それぞれがストレージデバイス及びプロセッサ等を含む複数のストレージ用の計算機が互いにネットワークで接続されることで構成される。各計算機は、ネットワークの中でノードとも呼ばれる。分散型ストレージシステムを構成する各計算機は特にストレージノードとも呼ばれ、コンピュートクラスタを構成する各計算機をコンピュートノードとも呼ばれる。
分散型ストレージシステムを構成するストレージノードには、ストレージノードを管理、制御するためのＯＳ（Operating System）がインストールされており、その上に、ストレージシステムの機能を持ったストレージソフトウェアを動作させる事で、分散型ストレージシステムが構成される。ストレージソフトウェアは、ＯＳ上でコンテナの形態で動作させることによっても、分散型ストレージシステムを構成することができる。コンテナとは、１つ以上のソフトウェアや構成情報をパッケージ化する仕組みである。また、ストレージノードにＶＭＭ（Virtual Machine Monitor）をインストールし、ＯＳ及びソフトウェアをＶＭ（Virtual Machine）として動作させて、分散型ストレージシステムを構成することもできる。
また、ＨＣＩ（Hyper-Converged Infrastructure）と呼ばれるシステムを構成する場合でも、本発明は適用可能である。ＨＣＩは、各ノードにインストールされたＯＳもしくはハイパーバイザの上に、ストレージソフトウェアの他にも、アプリケーション、ミドルウェア、管理ソフト、コンテナを動作させることで、１つのノードで複数の処理を実施することを可能にしたシステムである。
分散型ストレージシステムは、複数のストレージノード上のストレージデバイスの容量を仮想化したストレージプール及び論理ボリューム（単にボリュームとも呼ぶ）をホストに提供する。ホストが何れかのストレージノードに対してＩＯを発行すると、分散型ストレージシステムは、ＩＯコマンドが指定するデータを保持するストレージノードにＩＯコマンドを転送することで、データへのアクセスをホストに提供する。この特徴により、分散型ストレージシステムは、ホストからのＩＯコマンドを停止させることなく、各ストレージノード間でボリュームを移行することができる。
分散型ストレージシステムの管理者は、ネットワークを介して管理用コマンドを分散型ストレージに対して発行することで、ボリュームの作成、削除、移動等の処理を実施することができる。また、分散型ストレージシステムは、ネットワークを介して、分散型ストレージシステムが送信する情報を提供することで、分散型ストレージシステムにおけるドライブの使用状況やプロセッサの使用状況等、分散型ストレージシステムの状態を管理者や管理ツールに対して通知することができる。
本実施形態に係る分散型ストレージシステム１について詳しく説明する。
図１は、本発明の一実施形態に係る分散型ストレージシステム１の構成例を示すブロック図である。図１に示したように、分散型ストレージシステム１は、複数のストレージノード１０をネットワーク２０で互いに接続して構成される。各ストレージノード１０のハードウェア構成は特に限定されないが、例えば図１に示したストレージノード１０Ａのように、ＣＰＵ（Central Processing Unit）１１、メモリ１２、ネットワークインタフェース１３、ドライブインタフェース１４、ドライブ１５、及び内部ネットワーク１６等を有する。例えばストレージノード１０Ａは、ネットワークインタフェース１３を介してネットワーク２０に接続し、他のストレージノード１０Ｂ，１０Ｃと通信する。
なお、図１には図示を省略したが、分散型ストレージシステム１を構成する複数のストレージノード１０を接続するネットワーク２０は、同階層または階層の異なる複数のネットワーク２０が接続して構成されてもよい。そしてこれら複数のネットワーク２０の間の地理的な距離は限定されない。また、図１では、分散型ストレージシステム１を構成するストレージノード１０の一例としてストレージノード１０Ａ〜１０Ｃを示したが、本実施形態に係る分散型ストレージシステム１は、任意の数のストレージノード１０を備える構成であってよい。したがって、例えば、ストレージノード１０Ａ〜１０Ｃが接続するネットワーク２０が、地理的に十分に離れた場所で構成された別のネットワーク２０に接続され、この別のネットワーク２０にストレージノード１０Ｄやストレージノード１０Ｅが接続されているとすれば、災害対策として、ストレージノード１０Ａ〜１０Ｃのデータをストレージノード１０Ｄ，１０Ｅにも格納することが可能である。
また、図１では、分散型ストレージシステム１を構成するノードをすべてストレージノードとしているが、本実施形態で分散型ストレージシステム１を構成可能なノードは、ストレージノードに限定されるものではなく、例えば、ＨＣＩノードやコンピュートノード等であってもよい。
図２は、分散型ストレージシステム１を構成する各ノードのソフトウェアスタックの構成例を示すブロック図である。図２に示したように、１のストレージノード１０では、ハードウェアを制御するためのホストＯＳ（Operating System）２１が動作しており、その上には、１以上のゲストＯＳ２３（個別には２３Ａ〜２３Ｃ）をＶＭ（仮想マシン）として動作させるためのＶＭＭ（仮想マシンモニタ）２２が動作している。
そして、各ゲストＯＳ２３の上には、１以上のコンテナを動作させるためのコンテナランタイム２４（個別には２４Ａ〜２４Ｃ）が動作し、その上でストレージソフトウェア２５、管理ソフトウェア２６、コンピューティングソフトウェア２７が動作する。
なお、ストレージソフトウェア２５や管理ソフトウェア２６やコンピューティングソフトウェア２７は、必ずしも全てのストレージノード１０で動作する必要はない。また、管理ソフトウェア２６やコンピューティングソフトウェア２７は、分散型ストレージシステム１の外の物理ノード上で動作させる等してもよい。
また、上記のソフトウェアスタックにおいては、ホストＯＳ２１を省略し、ＶＭＭ２２が直接物理ノードにインストールされる構成をとることもできる。
また、ストレージソフトウェア２５、管理ソフトウェア２６、及びコンピューティングソフトウェア２７は、コンテナランタイム２４を介さずに、ゲストＯＳ２３上で動作させることも可能である。
また、上記各ソフトウェアをＶＭの形式をとらずに動作させることも可能であり、その場合は、ソフトウェアスタックにおいてＶＭＭ２２及びゲストＯＳ２３を省略することができる。さらに、その状態からコンテナランタイム２４を省略することも可能であり、その場合は、上記各ソフトウェアはホストＯＳ２１上で動作する。
図３は、ソフトウェアモジュールの分散型ストレージシステム１との関係を示す概要図である。図３に示したように、管理ソフトウェア２６は、ソフトウェアモジュールとして、管理コントローラ１００、モニタ２００、ボリュームクラシファイア３００、リソースクラシファイア４００、及びリバランサ５００を有する。上記の各ソフトウェアモジュールは、図３に示した矢印付きの実線に従って通信することが可能であり、後述する各種テーブルにアクセスしてデータを参照及び更新することができる。なお、図３に示した全てのソフトウェアモジュールが同じノード上で実装される必要はない。各ソフトウェアモジュールが実行される形態は、プロセスやコンテナ等、任意の方法でよい。また、図３では、管理ソフトウェア２６のソフトウェアモジュールの外部に分散型ストレージシステム１が存在するような記載をしているが、これは概念的な関係を示したものであり、実際には、図１及び図２に示したように、管理ソフトウェア２６は分散型ストレージシステム１を構成するノード（ストレージノード１０）内のソフトウェアスタックの１つと考えてよい。但し、各ソフトウェアモジュールが実行される場所は、ネットワーク２０を介して分散型ストレージシステム１にアクセスできる場所であれば、別のノード上であってもよい。
管理コントローラ１００は、その他のソフトウェアを決められたスケジュールに従って呼び出すソフトウェアである。
モニタ２００は、分散型ストレージシステム１にアクセスして、時系列の性能情報（換言すれば負荷情報）を取得するモジュールである。負荷情報とは、各ボリュームに対して発行されるＩＯやマイグレーション等に起因する各リソース（ＣＰＵ、メモリ、ドライブ等）の負荷を示す情報である。負荷情報は、分散型ストレージシステム１がリソースごとの負荷情報として保持しているとしてもよいし、ＩＯの情報に基づいてリソースごとの負荷情報に変換するとしてもよい。モニタ２００は、管理コントローラ１００によって、図１３に後述するモニタ頻度テーブル１２７に示されるグループごとの頻度に従って呼び出され、負荷情報を取得して所定の格納先に記憶する。モニタ２００による処理の具体的な処理手順は、図１５を参照しながら後述する。
ボリュームクラシファイア３００は、分散型ストレージシステム１が備えるボリュームを複数のグループに分類するためのソフトウェアモジュールである。分散型ストレージシステム１では、多数のボリュームを多数のストレージノード１０上に格納しており、それらが異なる性能特性を持つため、各ストレージノード１０上に各ボリュームをどのように配置するかという課題がある。いくつかの最適化アルゴリズムでは、ボリューム同士の組み合わせ最適化問題を解くことによって最適なボリューム配置を探索するため、ボリューム数をｎとしたとき、Ｏ（ｎ２）で計算量が増大する。そこで本実施形態では、ボリュームのセットを複数のグループに分類して（グルーピング）、１グループあたりのボリューム数ｎを小さくすることにより、ボリューム同士の組み合わせ最適化問題における計算量を低減できるようにする。
図４は、本実施形態におけるボリュームのグルーピングの概念を説明するための図である。各ボリュームに対する負荷が時系列に応じて変動するものとしたとき、同じ負荷変動の周期を持つボリュームを同じグループにして同じノードに配置することにより、グループ内のボリューム間で互いの負荷の干渉が固定されるため、各ボリュームの負荷の合計負荷のピーク値の計算が容易になる。さらに、異なる時間に負荷のピークを持つボリューム同士を同じグループにして同じノードに配置することにより、グループ内のボリューム間で互いの負荷のピークが同時に発生せず、効率的に多くのボリュームを各ストレージノード１０に配置することができる。
具体的には、図４には、６つのボリューム「ＶＯＬ＿１」〜「ＶＯＬ＿６」について、各ボリュームに対する負荷（ワークロード）の時系列の変動が示されている。このような図４において、ボリューム「ＶＯＬ＿１」及びボリューム「ＶＯＬ＿２」は、負荷変動の周期（言い換えれば、ワークロードが変動する最長周期）が１日であり、かつ、負荷のピークが異なるタイミングにあることから、同じグループＡにグルーピングする。同様に、ボリューム「ＶＯＬ＿３」及び「ＶＯＬ＿４」は、負荷変動の周期が１週間であり、かつ、負荷のピークが異なるタイミングにあることから、同じグループＢにグルーピングする。また同様に、ボリューム「ＶＯＬ＿５」及び「ＶＯＬ＿６」は、負荷変動の周期が１か月であり、かつ、負荷のピークが異なるタイミングにあることから、同じグループＣにグルーピングする。
以上のように、ボリュームクラシファイア３００は、グループ内のボリューム間で互いの負荷が干渉せず、効率的に多くのボリュームを各ストレージノード１０に配置できるようにするために、負荷変動の最長周期（ワークロードが変動する最長周期）ごとに、ボリュームをグルーピングする。なお、各ボリュームにおける負荷変動の最長周期は、各ボリュームにおける負荷変動から、卓越した周期を持ついくつかの成分のうちの最長の周期を持つ成分を特定することによって決定できる。ボリュームクラシファイア３００による処理の具体的な処理手順は、図１６を参照しながら後述する。
リソースクラシファイア４００は、分散型ストレージシステム１における各ストレージノード１０の各リソースを分類するソフトウェアモジュールである。リソースクラシファイア４００は、ボリュームクラシファイア３００によるボリュームの複数のグループへの分類に合わせて、各ボリュームに割り当てられる各リソースを上記複数のグループに分類することにより、各ボリュームへの各リソースの割当量を動的に決定することができる。リソースクラシファイア４００による処理の具体的な処理手順は、図１８を参照しながら後述する。
図５は、本実施形態におけるリソースのグルーピングの概念を説明するための図である。図５には、分散型ストレージシステム１を構成するストレージノード１０Ａ〜１０Ｃが有するＣＰＵ１１をリソースの一例として、リソースに対するグルーピングのイメージが示されている。図５によれば、各ストレージノード１０Ａ〜１０Ｃの複数のＣＰＵ１１が、各ノードを跨いで４つのグループ（グループＡ〜Ｄ）にグルーピングされていることが分かる。なお、図５ではＣＰＵ１１について示したが、ストレージノード１０が有する他のリソースについても、同様の概念でグルーピングすることができる。
また、図５では、１または複数のノードに跨ってリソースを仮想的にグルーピングしているが、本実施形態におけるリソースのグルーピングはこれに限定されるものではなく、１または複数のノードごとに、リソースをグルーピングするようにしてもよい。但し、１または複数のノードに跨ってリソースを仮想的にグルーピングする場合には、ワークロードの周期が変わってボリュームのグルーピングに変更が生じる場合でも、ノード間で当該ボリュームのデータをマイグレーションしなくても済むという利点がある。
リバランサ５００は、複数のグループに分類された各ボリュームへの各リソースの割り当てを調整するソフトウェアモジュールである。リバランサ５００による処理の具体的な処理手順は、図１９〜図２１を参照しながら後述する。
図６は、メモリマップの構成例を示すブロック図である。図６に示すように、ストレージノード１０のメモリ１２には、本実施形態に係る分散型ストレージシステム１による処理で使用される各種のテーブルが記憶されている。
具体的には、メモリ１２には、ノード構成テーブル１２１、ボリューム負荷テーブル１２２、ノード負荷テーブル１２３、グループサイクルテーブル１２４、ボリュームグループテーブル１２５、ボリューム配置テーブル１２６、モニタ頻度テーブル１２７、及びリソースキャパシティテーブル１２８が記憶されている。各テーブルの詳細な説明は、図７〜図１４を参照しながら後述する。
以下に、図６に示した各テーブルについて、テーブル構成を詳しく説明する。なお、図示する各テーブルの具体例では、フィールドの値を省略して空欄とした箇所がある。
図７は、ノード構成テーブル１２１の構成例を示す図である。ノード構成テーブル１２１は、各ノード（ストレージノード１０）が搭載するハードウェアリソースに関するスペックを保持する。具体的には、ノード構成テーブル１２１は、ストレージノードＩＤ１２１１、プロセッサ周波数１２１２、プロセッサ数１２１３、メモリ１２１４、ノード間ネットワーク帯域幅１２１５、ドライブ数１２１６、ドライブ読み出しトータルスループット１２１７、ドライブ書き込みトータルスループット１２１８、及び合計容量１２１９のフィールドを有する。なお、合計容量１２１９には、対象のノード（ストレージノード１０）に搭載されたドライブ容量の合計値が記載される。
図８は、ボリューム負荷テーブル１２２の構成例を示す図である。ボリューム負荷テーブル１２２は、所定の時間間隔（以後、各時刻と称する）で各ボリュームにおけるＩＯワークロードの特性を保持する。具体的には、ボリューム負荷テーブル１２２は、時刻１２２１、ボリュームＩＤ１２２２、ランダム比１２２３、平均サイズ１２２４、リードＩＯＰＳ１２２５、ライトＩＯＰＳ１２２６、リード転送速度１２２７、及びライト転送速度１２２８のフィールドを有する。ボリューム負荷テーブル１２２には、モニタ２００が定期的に負荷情報の取得処理を実行することによって、時系列で負荷情報が記録される。
図９は、ノード負荷テーブル１２３の構成例を示す図である。ノード負荷テーブル１２３は、各時刻における、各ノード上のそれぞれのリソースの負荷を保持する。具体的には、ノード負荷テーブル１２３は、時刻１２３１、ストレージノードＩＤ１２３２、及びグループＩＤ１２３３のフィールドと、各リソースの負荷を示すフィールド（プロセッサ１２３４、メモリ１２３５、ドライブ１２３６、ノード間ネットワーク１２３７、ドライブ読み出し１２３８、ドライブ書き出し１２３９）とを有する。
ノード負荷テーブル１２３の各フィールドの値は、例えば、以下のように計算する事が出来る。ボリューム負荷テーブル１２２から、各ノードに格納されている各ボリュームのＩＯＰＳ、トランスファーレート、ランダム率、リード／ライトの比率から、各ノードのリソースへの負荷の程度を計算する事が出来る。各ノードが搭載する各リソースが許容できる最大負荷は、ノード構成テーブル１２１より計算出来るため、前記の各リソースの負荷を最大のリソース負荷で除算する事で、各リソース負荷の割合を計算可能である。
図１０は、グループサイクルテーブル１２４の構成例を示す図である。グループサイクルテーブル１２４は、グループと周期との対応関係を管理する。具体的には、グループサイクルテーブル１２４は、グループＩＤ１２４１及び周期１２４２のフィールドを有する。前述した通り、本実施形態では、ボリュームは負荷変動の周期に応じてグループに分類される。周期１２４２は、図１０に例示するものに限定されず、例えば、２日等、任意の期間を指定可能である。また、グループの数も任意に設定可能である。なお、本実施形態では、図４及び図５を参照しながら説明したように、ボリュームと同じ分類（グループ）でリソースを分類する。したがって、グループサイクルテーブル１２４に示されるグループＩＤ１２４１は、リソースのグループＩＤ（例えば図９のノード負荷テーブル１２３のグループＩＤ１２３３）と、ボリュームのグループＩＤ（例えば、図１１のボリュームグループテーブル１２５のボリュームＩＤ１２５１等）の双方に適用される。
図１１は、ボリュームグループテーブル１２５の構成例を示す図である。ボリュームグループテーブル１２５は、ボリュームとグループとの対応関係を管理する。具体的には、ボリュームグループテーブル１２５は、ボリュームＩＤ１２５１及びグループＩＤ１２５２のフィールドを有する。
図１２は、ボリューム配置テーブル１２６の構成例を示す図である。ボリューム配置テーブル１２６は、ボリュームと配置先のノードとの対応関係を管理する。具体的には、ボリューム配置テーブル１２６は、ボリュームＩＤ１２６１、使用容量１２６２、及びストレージノードＩＤ１２６３のフィールドを有する。なお、使用容量１２６２には、ボリュームＩＤ１２６１に対応するボリュームに割り当てられたドライブ容量の合計値が記載される。
図１３は、モニタ頻度テーブル１２７の構成例を示す図である。モニタ頻度テーブル１２７は、各グループに対するモニタ２００による負荷情報の取得頻度（モニタ頻度）を管理する。具体的には、モニタ頻度テーブル１２７は、グループＩＤ１２７１及びモニタ頻度１２７２のフィールドを有する。ボリュームの負荷変動は、短期間に頻繁に変動するものや、長期間に緩やかに変動するもの等、様々であり、リバランサ５００によるボリュームの再配置を最適化する際の計算量を削減するために、モニタ頻度テーブル１２７では、モニタ２００が負荷情報の取得処理を実行する頻度を示すモニタ頻度１２７２がグループ（グループＩＤ１２７１）ごとに設定される。モニタ頻度１２７２の決定方法は、例えば、ボリュームの負荷変動の波形を構成する成分をスペクトル解析等で分析し、卓越した周期を持ついくつかの成分のなかで、最短の周期を持つ成分の半分の頻度とすることで、必要十分な負荷情報を保存することが可能である。なお、図１３のモニタ頻度テーブル１２７では、グループ（グループＩＤ１２７１）を単位としてモニタ頻度１２７２を調整するとしたが、例えば、ボリューム（ボリュームＩＤ）を単位としてモニタ頻度１２７２を調整するようにしてもよい。
図１４は、リソースキャパシティテーブル１２８の構成例を示す図である。リソースキャパシティテーブル１２８は、各ノードが備える複数のリソースそれぞれについて、グループ単位で、割り当てられたリソースの過不足を管理する。具体的には、リソースキャパシティテーブル１２８は、ノードＩＤ１２８１、リソース１２８２、グループＩＤ１２８３、割当量１２８４、及び必要量１２８５のフィールドを有する。このうち、割当量１２８４は、現在、各グループに割り当てられているリソース量を示すものであり、１のノードにおける全グループ分の割当量１２８４の合計は、当該ノードのハードウェア構成、すなわち、図７のノード構成テーブル１２１において当該ノードに対応する合計容量１２１９の値と一致する。これに対して、必要量１２８５は、各グループに含まれるボリュームに対するワークロードを処理するために必要なリソース量を示す。必要量１２８５は、リソースクラシファイア４００の処理によって更新され、必要量１２８５と割当量１２８４との差分に基づいて、リバランサ５００が、グループ間でのリソースの割当量を調整する。
図１５は、モニタ２００による処理の処理手順例を示すフローチャートである。モニタ２００は、図１３のモニタ頻度テーブル１２７が示すグループごとの負荷情報の取得頻度（モニタ頻度１２７２）にしたがって管理コントローラ１００から呼び出され、図１５に示す処理手順で、負荷情報を取得する処理を実行する。
具体的にはまず、モニタ２００は、分散型ストレージシステム１にアクセスして、各ボリューム及び各ボリュームを提供するノードの負荷情報を取得する（ステップＳ１１）。
次に、モニタ２００は、ステップＳ１１で取得した負荷情報を、図８に示したボリューム負荷テーブル１２２及び図９に示したノード負荷テーブル１２３に格納する（ステップＳ１２）。より具体的には、モニタ２００は、取得したボリュームの負荷情報を、ボリューム負荷テーブル１２２のランダム比１２２３〜ライト転送速度１２２８のフィールドに格納し、取得したノードの負荷情報を、ノード負荷テーブル１２３のプロセッサ１２３４〜ドライブ書き出し１２３９のフィールドに格納する。
以上、ステップＳ１１〜Ｓ１２の処理が行われることにより、モニタ２００は、モニタ頻度テーブル１２７に定められた頻度で、ボリューム及びノードの負荷情報を取得し、記録することができる。
なお、上述したモニタ２００によるステップＳ１１〜Ｓ１２の処理は、詳細には以下の何れの手順で実行されてもよい。例えば、モニタ２００は、ステップＳ１１で、モニタ頻度テーブル１２７においてモニタ頻度１２７２に対応するグループ（グループＩＤ１２７１）だけを対象として、当該グループに属するボリュームやノードの負荷情報のみを分散型ストレージシステム１から取得し、ステップＳ１２で、取得した負荷情報をボリューム負荷テーブル１２２やノード負荷テーブル１２３に格納するようにしてもよい。また例えば、モニタ２００は、ステップＳ１１では、分散型ストレージシステム１に含まれる全てのボリュームやノードの負荷情報を分散型ストレージシステム１から取得し、ステップＳ１２で、ステップＳ１１で取得した負荷情報のうち、当該グループに属するボリュームやノードの負荷情報のみをボリューム負荷テーブル１２２やノード負荷テーブル１２３に格納するようにしてもよい。
図１６は、ボリュームクラシファイア３００による処理の処理手順例を示すフローチャートである。
図１６によればまず、ボリュームクラシファイア３００は、全グループ分のループ処理を開始する（ステップＳ２１）。具体的には、ボリュームクラシファイア３００は、図１１のボリュームグループテーブル１２５を参照し、グループＩＤ１２５２にＩＤが示された全グループのうちから、未処理のグループを１つ選択する。
次に、ボリュームクラシファイア３００は、ステップＳ２１で選択したグループに含まれる全ボリューム分のループ処理を開始する（ステップＳ２２）。具体的には、ボリュームクラシファイア３００は、ボリュームグループテーブル１２５を参照して、ステップＳ２１で選択したグループ（グループＩＤ１２５２）と対応関係にあるボリューム（ボリュームＩＤ１２５１）を全て検索し、該当する全ボリュームのうちから、未処理のボリュームを１つ選択する。
次に、ボリュームクラシファイア３００は、ボリューム負荷テーブル１２２を参照し、ステップＳ２２で選択した１つのボリュームにおける全時刻の負荷情報を取得する（ステップＳ２３）。
次に、ボリュームクラシファイア３００は、ステップＳ２３で取得した全時刻分の負荷情報からなる負荷変動を分析し、負荷変動の最長の周期を特定する（ステップＳ２４）。なお、ステップＳ２４において負荷変動を分析する具体的な方法として、例えば、負荷変動の波形における卓越した周期を抽出する等の方法が考えられる。この場合、負荷変動の波形にスペクトル解析等を行って波形を分解することにより、即座に最長の周期を特定することが可能となる。
ここで、図１７は、負荷変動の波形の分解を説明するための図である。図１７の左側には、負荷変動の波形の一例として、波形（Ａ）が示されている。この波形（Ａ）は周期性を持つ波形であり、いくつかの正弦波に分解することができる。また、図１７の右側には、波形（Ａ）にスペクトル解析を行って分解された３種類の正弦波の波形（Ｂ１〜Ｂ３）が示されている。
ボリュームの負荷はワークロードの周期に沿って変動し、あるボリュームにいくつかのワークロードが混在する場合、当該ボリュームにおける負荷変動の波形は、ワークロードごとの負荷変動を合わせた周期的な波形で表される。したがって、周期性を有するボリュームの負荷変動の波形は、各ワークロードの負荷変動を表すいくつかの正弦波に分解することができ、各正弦波の周期から最長の周期を特定することにより、ボリュームの負荷変動の把握に必要十分な情報量を保持することが可能となる。
具体的には、図１７の波形（Ａ）に対してステップＳ２４の処理を行う場合、まずは、波形（Ａ）をスペクトル解析して得られた波形（Ｂ１〜Ｂ３）について、それぞれの波形の周期を特定する。この場合、波形（Ｂ１）の周期Ｔ１は「１」であり、波形（Ｂ２）の周期Ｔ２は「１／２」であり、波形（Ｂ３）の周期Ｔ３は「１／３」である。言い換えれば、周期Ｔ１は、周期Ｔ２の２倍であり、周期Ｔ３の３倍である。すなわち、分解された波形（Ｂ１〜Ｂ３）の最長の周期は「１」の周期Ｔ１であり、分解前の波形（Ａ）における最長の周期Ｔを「１」と特定することができる。
そして上記のように、最長周期でグルーピングされたグループにおいては、リバランサ５００に入力する情報を、ワークロードが変動する最長周期Ｔと同じ長さのデータ量とする（最長周期より長いデータを入力しないようにする）ことで、リバランサ５００がボリュームの負荷変動を考慮して各リソースの割り当てを調整するために必要十分なデータが担保される。なお、リバランサ５００に入力するデータ量が、ワークロードが変動する最長周期（負荷変動の最長周期）を超えるデータ量とならないようにするために、モニタ２００による負荷情報の取得において、モニタ２００が上記最長周期のデータから負荷情報を取得するように制限するようにしてもよい。このようにモニタ２００側で負荷情報を取得するデータ量を制限する場合、ボリューム負荷テーブル１２２（図８参照）やノード負荷テーブル１２３（図９参照）の情報も上記制限されたデータ量に基づいて表されるため、結果として、リバランサ５００には、ボリュームの負荷変動を考慮して各リソースの割り当てを調整するために必要十分なデータが、上記最長周期を超えないデータ量で入力される。
図１６の説明に戻る。ステップＳ２４の処理後、ボリュームクラシファイア３００は、ステップＳ２４で特定した最長の周期を、図１０のグループサイクルテーブル１２４が保持する周期１２４２の何れか（すなわち、１日、１週間、１か月、１年の何れか）に近似し、近似した周期１２４２に対応するグループＩＤ１２４２によって、ステップＳ２２で選択したボリュームを分類する（ステップＳ２５）。具体的には例えば、ステップＳ２４において、あるボリュームにおける負荷変動の最長の周期が「１．５日」と特定された場合、ステップＳ２５では、「１．５日」に最も近い周期として「１日（Ｄａｙ）」の周期１２４２が選択され、この結果、当該ボリュームは「１１１１−１１１１−１１１１−１１１１」のグループＩＤ１２４１を有するグループＡに分類される。
次に、ボリュームクラシファイア３００は、ステップＳ２５で決定したボリュームの分類に従って、図１１のボリュームグループテーブル１２５を更新する（ステップＳ２６）。
以降、ボリュームクラシファイア３００は、ステップＳ２２で述べたように、ステップＳ２３〜Ｓ２６の処理を、ステップＳ２１で選択したグループに含まれる全ボリューム分について繰り返し実行し、さらに、ステップＳ２１で述べたように、これらステップＳ２２〜Ｓ２６の処理を、全グループ分について繰り返し実行する。そしてボリュームクラシファイア３００は、ステップＳ２１のループ処理が終わると、図１６の全処理を終了する。
以上、ステップＳ２１〜Ｓ２６の処理が行われることにより、ボリュームクラシファイア３００は、分散型ストレージシステム１が備える複数のボリュームを、各ボリュームの性能特性（負荷変動の最長周期）に応じて、複数のグループに分類することができる。そして、ステップＳ２５で特定されたボリュームごとの周期１２４２が、後述するリバランサ５００への入力データの長さ（期間）となる。なお、図４を参照して前述したように、ボリュームの分類基準となる「負荷変動の最長周期」は、当該ボリュームに含まれる「ワークロードが変動する最長周期」に相当する。
図１８は、リソースクラシファイア４００による処理の処理手順例を示すフローチャートである。
図１８によればまず、リソースクラシファイア４００は、全ノード分のループ処理を開始する（ステップＳ３１）。具体的には、リソースクラシファイア４００は、図１４のリソースキャパシティテーブル１２８を参照し、ノードＩＤ１２８１にＩＤが示された全ノードのうちから、未処理のノードを１つ選択する。
次に、リソースクラシファイア４００は、ステップＳ３１で選択したノードにおける全グループ分のループ処理を開始する（ステップＳ３２）。具体的には、リソースクラシファイア４００は、リソースキャパシティテーブル１２８を参照して、ステップＳ３１で選択したノード（ノードＩＤ１２８１）に属するグループ（グループＩＤ１２８３）を全て検索し、該当する全グループのうちから未処理のグループを１つ選択する。
次に、リソースクラシファイア４００は、ステップＳ３２で選択したグループについて、全時刻分のループ処理を開始する（ステップＳ３３）。具体的には、リソースクラシファイア４００は、図９のノード負荷テーブル１２３を参照し、時刻１２３１に記録された全ての時刻のうちから、未処理の時刻を１つ選択する。
次に、リソースクラシファイア４００は、図９のノード負荷テーブル１２３を参照し、ステップＳ３３で選択した時刻において、ステップＳ３２で選択したグループに含まれる全ボリュームの負荷を合計する（ステップＳ３４）。なお、ステップＳ３４の処理は、リソースごとに全てのリソースについて実行される。
次に、ステップＳ３３で述べたように、リソースクラシファイア４００は、ステップＳ３４の処理を全時刻分について繰り返し実行する。このループ処理によって、リソースクラシファイア４００は、ステップＳ３２で選択したグループに含まれる全ボリュームの合計負荷を、時刻ごとかつリソースごとに算出することができる。
次に、リソースクラシファイア４００は、ステップＳ３３〜Ｓ３４の処理で算出した時刻ごとのグループ内の全ボリュームの合計負荷のうち、最も高い合計負荷となった時刻を取得する（ステップＳ３５）。ステップＳ３５の処理も、ステップＳ３４の処理と同様に、リソースごとに全てのリソースについて実行される。なお、ステップＳ３５において取得する時刻の選定方法は、最も高い合計負荷となった時刻に限定されるものではなく、例えば、合計負荷の平均値が最も高い時刻を取得する等であってもよい。合計負荷の最大値などの値により、そのグループが発生させうる負荷としてグループ負荷を定義する。
次に、リソースクラシファイア４００は、当該グループにおける各リソースの必要量を計算し、リソースキャパシティテーブル１２８を更新する（ステップＳ３６）。ステップＳ３６において各リソースの必要量は、例えば、図７のノード構成テーブル１２１に示される各ノードのハードウェアリソース量から定まるノードの最大負荷に対して、ステップＳ３５で取得した時刻における最大負荷の割合（ステップＳ３４で求めた負荷の合計）を掛けることによって、算出することができる。そしてリソースクラシファイア４００は、算出したリソースの必要量で、図１４のリソースキャパシティテーブル１２８の必要量１２８５を更新する。
以降、リソースクラシファイア４００は、ステップＳ３２で述べたように、ステップＳ３３〜Ｓ３６の処理を、ステップＳ３１で選択したノードに含まれる全グループ分について繰り返し実行し、さらに、ステップＳ３１で述べたように、これらステップＳ３２〜Ｓ３６の処理を、全ノード分について繰り返し実行する。そしてリソースクラシファイア４００は、ステップＳ３１のループ処理が終わると、図１８の全処理を終了する。
以上、ステップＳ３１〜Ｓ３６の処理が行われることにより、リソースクラシファイア４００は、ボリュームクラシファイア３００によるボリュームに対するグループの分類に合わせて、ボリュームのグループごとに、各ボリュームに割り当てられる各リソースの割当量を動的に決定することができる。
図１９は、リバランサ５００による処理の処理手順例を示すフローチャートである。
図１９によればまず、リバランサ５００は、図１４のリソースキャパシティテーブル１２８を参照し、あるノード内で、必要量１２８５が割り当て済みのリソース量（割当量１２８４）を上回っているリソースが存在するか否かを判定する（ステップＳ４１）。
ステップＳ４１で肯定結果が得られた場合には（ステップＳ４１のＹＥＳ）、ノード内のグループ間でリソースの不均衡が生じていることを意味する。この場合、リバランサ５００は、ステップＳ４２に進み、グループ調整処理を呼び出して実行することにより、当該ノードにおけるグループ間のリソースの割り当てを調整する。
ここで、ステップＳ４２においてリバランサ５００が実行するグループ調整処理について、図２０を参照しながら詳しく説明する。図２０は、グループ調整処理の処理手順例を示すフローチャートである。
図２０によればまず、リバランサ５００は、全ノード分のループ処理を開始する（ステップＳ５１）。具体的には、リバランサ５００は、図１４のリソースキャパシティテーブル１２８を参照し、ノードＩＤ１２８１にＩＤが示された全ノードのうちから、未処理のノードを１つ選択する。
次に、リバランサ５００は、ステップＳ５１で選択したノードが有する全リソース分のループ処理を開始する（ステップＳ５２）。具体的には、リバランサ５００は、リソースキャパシティテーブル１２８を参照し、ステップＳ５１で選択したノード（ノードＩＤ１２８１）を含むレコードにおいてリソース１２８２に示された各リソースのうちから、未処理のリソースを１つ選択する。
次に、リバランサ５００は、ステップＳ５２で選択したリソースについて、当該リソースが属する全グループ分のループ処理を開始する（ステップＳ５３）。具体的には、リバランサ５００は、リソースキャパシティテーブル１２８を参照し、ステップＳ５２で選択したリソース１２８２を含むレコードにおいてグループＩＤ１２８３に示された全グループのうちから、未処理のグループを１つ選択する。
次に、リバランサ５００は、リソースキャパシティテーブル１２８を参照し、ステップＳ５３で選択されたグループＩＤ１２８３のグループ（第１のグループ）のレコードにおいて、必要量１２８５の値が割当量１２８４を上回っているか否かを判定する（ステップＳ５４）。ステップＳ５４において肯定結果が得られた場合（ステップＳ５４のＹＥＳ）、第１のグループに割り当てられたリソース量がワークロードを処理するために必要なリソース量に対して不足していることを意味しており、この場合、ステップＳ５５の処理が行われる。一方、ステップＳ５４において否定結果が得られた場合には（ステップＳ５４のＮＯ）、ステップＳ５５〜Ｓ５７の処理をスキップしてステップＳ５３のループ処理に戻る。
ステップＳ５５では、リバランサ５００は、ステップＳ５１で選択されたノード上のステップＳ５２で選択されたリソースについて、必要量１２８５が割当量１２８４よりも小さい、第１のグループとは別のグループ（第２のグループ）が存在するか否かを判定する。ステップＳ５５で肯定結果が得られた場合（ステップＳ５５のＹＥＳ）、第２のグループに割り当てられたリソース量がワークロードを処理するために必要なリソース量に対して余剰があることを意味しており、このときステップＳ５６の処理が行われる。一方、ステップＳ５５において否定結果が得られた場合には（ステップＳ５５のＮＯ）、ステップＳ５６〜Ｓ５７の処理をスキップしてステップＳ５３のループ処理に戻る。
ステップＳ５６では、リバランサ５００は、同一ノード内の第２のグループから第１のグループに対してリソースを融通するようにリソースの割り当てを変更し、変更後の割当量で、図１４のリソースキャパシティテーブル１２８の割当量１２８４を更新する。より具体的には、リバランサ５００は、例えば、第２のグループの割当量１２８４から必要量１２８５を差し引いた余剰量の一部を、第１のグループの割当量１２８４に割り当てるように、リソースの割り当てを変更すればよい。またこのとき、１つの第２のグループの余剰量だけでは第１のグループのリソースの不足量を相殺できない場合には、複数の第２のグループの余剰量を第１のグループの割当量に回すようにリソースの割り当てを変更してもよい。このようにステップＳ５６の処理が行われることにより、同一ノード内のグループ間でリソースを融通し合うことができる。
次に、リバランサ５００は、ステップＳ５６で更新されたリソースキャパシティテーブル１２８に基づいて、図９のノード負荷テーブル１２３を更新する（ステップＳ５７）。具体的には例えば、リソースの更新後の割当量１２８４と更新前の割当量１２８４との比率を各時刻の負荷に適用することで、当該リソースの負荷を計算することができる。
以降、リバランサ５００は、ステップＳ５３で述べたように、ステップＳ５４〜Ｓ５７の処理を、ステップＳ５２で選択したリソースが属する全グループ分について繰り返し実行し、さらに、ステップＳ５２で述べたように、ステップＳ５３〜Ｓ５７の処理を、ステップＳ５１で選択したノードが有する全リソース分について繰り返し実行し、さらに、ステップＳ５１で述べたように、これらステップＳ５２〜Ｓ５７の処理を、全ノード分について繰り返し実行する。そしてリバランサ５００は、ステップＳ５１のループ処理が終わると、図２０の全処理を終了する。
以上、ステップＳ５１〜Ｓ５７の処理が行われることにより、リバランサ５００は、ボリュームのグループごとに、同一ノード内でグループ間のリソースの割り当てを調整することができる。
図１９の説明に戻る。ステップＳ４１で肯定結果が得られてステップＳ４２のグループ調整処理が実行された後、あるいは、ステップＳ４１で否定結果が得られた場合（ステップＳ４１のＮＯ）、リバランサ５００はステップＳ４３の処理を行う。
ステップＳ４３では、リバランサ５００は、図９のノード負荷テーブル１２３を参照し、各リソースの負荷が所定の上限値を超えている時間帯が存在するか否かを判定する。
ステップＳ４３で肯定結果が得られた場合には（ステップＳ４３のＹＥＳ）、ノード間でリソースの不均衡が生じていることを意味する。この場合、リバランサ５００は、ステップＳ４４に進み、ボリューム再配置処理を呼び出して実行することにより、ノード間でボリュームのマイグレーション（移行）を行ってリソースの割り当てを調整する。
ここで、ステップＳ４４においてリバランサ５００が実行するボリューム再配置処理について、図２１を参照しながら詳しく説明する。図２１は、ボリューム再配置処理の処理手順例を示すフローチャートである。
図２１によればまず、リバランサ５００は、全てのグループを対象とするループ処理を開始する（ステップＳ６１）。具体的には、リバランサ５００は、図１１のボリュームグループテーブル１２５を参照して、グループＩＤ１２５２にＩＤが示された全グループのうちから、ステップＳ６２〜Ｓ６７の処理が行われていない未処理のグループを１つ選択する。以後、ここで選択したグループを「当該グループ」と称する。
次に、リバランサ５００は、当該グループに属する全ての移行元ボリュームを対象とするループ処理を開始する（ステップＳ６２）。移行元ボリュームを選択する順番について、例えば、負荷の閾値を超えている度合いが高い順に対象とする。このように選択する事で、全てのボリュームの移行先ノードを見つけられない場合でも、負荷に対して閾値を超えている度合いが高いボリュームを優先的に選択できる。ステップＳ６２において具体的には、リバランサ５００は、図８のボリューム負荷テーブル１２２を参照して、ステップＳ６１で選択した当該グループに対応する全ボリューム（図１１参照）のうち、各リソースの負荷情報（ランダム比１２３３〜ライト転送速度１２２８）が所定の閾値を超えているボリューム（移行元ボリューム）を検索し、検索された移行元ボリュームのうちから、ステップＳ６３〜Ｓ６７の処理が未だ行われていない未処理の移行元ボリュームを１つ選択する。
次に、リバランサ５００は、全ての移動先ノードを対象とするループ処理を開始する（ステップＳ６３）。上記「移動先ノード」は、移行元ボリュームの移動先候補となるノードを定義した用語であり、ステップＳ６２で選択した移行元ボリュームが属するノードを除外した、リソースを備える全てのノードが該当する。ステップＳ６３において具体的には、リバランサ５００は、図１４のリソースキャパシティテーブル１２８を参照し、ノードＩＤ１２８１にＩＤが示された全ノードからステップＳ６２で選択した移行元ボリュームが属するノードを除いた移行先ノードのうちから、ステップＳＳ６４〜Ｓ６６の処理が行われていない未処理の移行先ノードを１つ選択する。
次に、リバランサ５００は、ステップＳ６２で選択した移行元ボリュームがステップＳ６３で選択した移行先ノードにマイグレーションされると仮定する（ステップＳ６４）。
次に、リバランサ５００は、ステップＳ６４のマイグレーションの仮定のもとで、移行先ノード上で当該グループに属する全てのボリュームを対象に、各ボリュームを移行先ボリュームとしてループ処理を開始する（ステップＳ６５）。
このステップＳ６５のループ処理において、リバランサ５００は、ステップＳ６４のマイグレーションを仮定した状況において、移行先ノード上で当該グループに属する全ボリュームによるグループ負荷の予想値（以後、「移行先ノードの予想グループ負荷」と称する）を算出する。具体的には、リバランサ５００は、ステップＳ６５のループ処理開始時には、移行先ノードの予想グループ負荷を「０」とし、ステップＳ６６において、移行先ノードの予想グループ負荷に、移行先ボリュームの負荷を加算する。そして、ステップＳ６５のループ処理において、リバランサ５００は、移行先ノード上で当該グループに属する各ボリューム（移行先ボリューム）について、ステップＳ６６の処理を繰り返し実行する。このように、ステップＳ６５のループ処理によってリバランサ５００は、移行先ノード上で当該グループに属する全ボリューム（移行候補のボリュームを含む）の負荷を合計した値を、「移行先ノードの予想グループ負荷」として算出することができる。
さらに、上記ステップＳ６４〜Ｓ６６の処理が繰り返し実行されてステップＳ６３のループ処理が終了すると、全ての移行先ノードの候補について、移行元ボリュームを移行先ノードにマイグレーションした場合における、移行先ノードの予想グループ負荷が算出される。
そして、ステップＳ６３のループ処理の結果を基に、リバランサ５００は、移行先ノードの各候補についての移行先ノードの予想グループ負荷を比較して、最も少ない予想グループ負荷を有する候補ノードを、移行元ボリュームを実際にマイグレーションする移行先ノードに選択する（ステップＳ６７）。前述したように、移行先ノードの予想グループ負荷は、移行先ノード上で当該グループに属する各ボリュームの負荷の合計値であり、この合計値は、各ボリュームにおける負荷のピークが重なる場合よりも、分散する（ずれている）場合に小さくなる傾向がある。すなわち、ステップＳ６７においてリバランサ５００は、各ボリュームにおける負荷のピークのずれを重視して、移動させた場合に移動先のグループ負荷の増加が小さいノードを移行先ノードとして選定を行う。
次いで、リバランサ５００は、Ｓ６７で選定（決定）した移行元ボリュームの移行先ノードに従って、移行元ボリュームが属するノードと、移行先ノードの当該グループのグループ負荷を更新する。（ステップＳ６８）。
これにより、先に移行先ノードを決定した移行元ボリュームの負荷も考慮しつつ、後続のボリュームについても移行先ノードを決定する事が可能である。
そして、上記ステップＳ６３〜Ｓ６８の処理が繰り返し実行されてステップＳ６２のループ処理が終了すると、当該グループに属するボリュームのうち、負荷が所定の閾値を超えている各ボリューム（移行元ボリューム）について、マイグレーションの移行先ノードが選択され、当該グループのグループ負荷が閾値以下になっている状態となる。
ステップＳ６２のループ処理が終了すると、リバランサ５００は、ステップＳ６１で選択した当該グループに対するボリューム再配置処理の経過時間が、グループ毎に定められた制限時間を超えていないか判定する（ステップＳ６９）。経過時間が制限時間以内である場合は（ステップＳ６９のＮＯ）、ステップＳ７０に進み、経過時間が制限時間を超えている場合は（ステップＳ６９のＮＯ）、ステップＳ７０をスキップする。
ステップＳ７０において、リバランサ５００は、当該グループにおいてグループ負荷が閾値を超えているノードがあるか判定する（ステップＳ７０）。グループ負荷が閾値を超えているノードがある場合は（ステップＳ７０のＹＥＳ）、ステップＳ６２に戻り、グループ負荷が閾値を超えているノードがない場合は（ステップＳ７０のＮＯ）、Ｓ６１のループ処理を続行する。
そして、ステップＳ６１のループ処理として、上記ステップＳ６２〜Ｓ７０の処理が繰り返し実行されることにより、リバランサ５００は、全てのグループについて、マイグレーションが実行されるボリューム（移行元ボリューム）とその移動先のノード（移行先ノード）とを決定することができる。そしてリバランサ５００は、この決定にしたがって、任意のタイミングで、移行元ボリュームの移行先ノードへのマイグレーションを実行する。
以上、ステップＳ６１〜Ｓ７０の処理が行われることにより、リバランサ５００は、各グループ内のノード間でボリュームのマイグレーションを行ってリソースの割り当てを調整することができる。
図１９の説明に戻る。ステップＳ４３で肯定結果が得られてステップＳ４４のボリューム再配置処理が実行された後、あるいは、ステップＳ４３で否定結果が得られた場合（ステップＳ４３のＮＯ）、リバランサ５００は処理を終了する。
以上ステップＳ４１〜Ｓ４４の処理が実行されることにより、本実施形態のリバランサ５００は、割り当て済みのリソース量（割当量１２８４）とワークロードを処理するために必要なリソース量（必要量１２８５）との間に不均衡が発生している場合に、グループ調整処理によってノード内のグループ間でリソースの不均衡を調整し（ステップＳ４２）、ノード間で各リソースの負荷に不均衡が発生している場合に、ボリューム再配置処理によって同一グループ内のノード間でボリュームのマイグレーションを行ってリソースの不均衡を調整する（ステップＳ４４）。この結果、リバランサ５００は、各グループの分類された各ボリュームへの各リソースの割り当てを調整することができる。なお、図１９に示した処理手順のようにボリューム再配置処理より先にグループ調整処理を実行する場合、グループ調整処理の実行だけでリソースの不均衡が解消された場合には、ノード間でマイグレーションを行わずに済むため、システム（例えばハイパーバイザ）側の処理時間を短縮できる効果に期待できる。
以上に説明したように、本実施形態に係る分散型ストレージシステム１では、モニタ２００が、所定の取得頻度で複数のボリュームの各ボリュームにおける負荷情報を取得し、ボリュームクラシファイア３００が、複数のボリュームを、各ボリュームにおける負荷の変動周期（より具体的には、ワークロードが変動する最長周期）に基づいて、複数のグループに分類することにより、リバランサ５００によるリバランスの計算対象となる、ボリューム数及び時間ごとの負荷情報の数を低減することができる。また、リソースクラシファイア４００が、複数のボリュームの複数のグループへの分類に応じて、複数のノードが有する各リソースを複数のグループに分類することで、各ボリュームに割り当てられる各リソースの割当量を動的に決定することができる。本実施形態に係る分散型ストレージシステム１は、これらモニタ２００、ボリュームクラシファイア３００及びリソースクラシファイア４００の構成を備えることによって、リバランサ５００が、各グループのなかで各ボリュームへの各リソースの割り当てを調整するリバランスの処理を実行する際、ボリューム間の組み合わせ最適化計算の計算量を低減することができる。
ここで、本実施形態におけるリバランスの計算量（ボリューム間の組み合わせ最適化計算）の低減効果について詳しく説明する。
従来、様々なワークロードが混在する分散型ストレージシステムでは、データの要件を満たせるように各ノード上で各ボリュームを適切に配置するために、各ノード上の最適なボリューム配置を探索する最適化アルゴリズムが用いられる。この代表的な最適化アルゴリズムでは、ボリューム同士の組み合わせ最適化問題を解くことで、最適なボリューム配置を探索する事が可能であるが、その計算量は、ボリューム数をｎとしたとき、Ｏ（ｎ２）で増大する。これは、リバランスの処理によって、移行元の各ボリュームを別のノードに移行した場合に、移行先ノード上のボリュームの負荷も含めて、各時刻における負荷を計算し、ボリュームの配置案を探索するため、ボリュームの組み合わせ数に応じて計算量が増大するためである。そのため、従来の分散型ストレージシステムでは、ボリューム数ｎが多い大規模な環境では、ボリューム同士の組み合わせ最適化問題の計算量が非常に大きなものとなり、計算が長期化するためにタイムリーな対処が難しいという課題があり、最適化問題を解くために大量の計算用リソースが必要になるという課題もあった。
上記課題に対して、本実施形態に係る分散型ストレージシステム１では、分散型ストレージシステム１が提供する複数のボリュームを複数のグループに分類することで、１グループあたりのボリューム数を小さくすることができる。そしてリバランサ５００は、リバランスの処理として、各グループのなかでボリューム間の組み合わせ最適化計算を行って各ボリュームへの各リソースの割り当てを調整することから、例えば複数のボリュームをｎグループに分割するとすれば、ボリューム間の組み合わせ最適化計算の計算量は、下記の式１に表すように「１／ｎ」に低減することができる。
Figure 2021197010
 すなわち、本実施形態に係る分散型ストレージシステム１は、リバランサ５００によるリバランスの処理において、計算対象のボリューム数を低減することで、ボリューム間の組み合わせ最適化計算の計算量を低減することができ、従来の分散型ストレージシステムよりも短い期間でリバランスの処理を実施することができる。
また、本実施形態において、モニタ２００が、周期的にボリュームの負荷情報を取得する際に、ボリュームのグルーピングに用いられた負荷変動の周期（ワークロードが変動する最長周期）のデータ長で負荷情報を取得する場合、リバランサ５００によるリバランスの計算処理のために必要十分な情報を、最適なデータ長で取得することができる。そしてこのデータ長をリバランサ５００への入力データのデータ長とすることにより、リバランサ５００はリバランスの処理をさらに効率的に計算することができる。また、負荷情報を記憶する計算リソースを削減する効果にも期待できる。
また、本実施形態において、各ボリュームに対する負荷は、時系列に応じて負荷が変動するものとしたとき、同一または近似する負荷変動の周期（ワークロードが変動する周期）を持ち、異なる負荷のピークを持つボリューム同士を同じノードに配置することで、お互いの負荷が干渉せず、効率的に多くのボリュームを各ストレージノードに配置することができる。そのため、ボリュームの負荷変動の周期に応じてボリュームをグルーピングする事で、効率的なグルーピングが可能となる。
以上のように、本実施形態に係る分散型ストレージシステム１によれば、ボリューム間の組み合わせ最適化計算の計算量を削減することができ、タイムリーなストレージシステムの管理と計算リソースの削減を実現することができる。なお、本実施形態に係る分散型ストレージシステム１は、プライベートクラウドのようにノード数が多く、さまざまなワークロードが混在しており、人手による負荷の予測と最適化が困難なユースケースに対してより好適である。
なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、図面において制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実施には殆ど全ての構成が相互に接続されていると考えてもよい。
１ 分散型ストレージシステム
１０（１０Ａ，１０Ｂ，１０Ｃ） ストレージノード
１１ ＣＰＵ
１２ メモリ
１３ ネットワークインタフェース
１４ ドライブインタフェース
１５ ドライブ
１６ 内部ネットワーク
２０ ネットワーク
２１ ホストＯＳ
２２ ＶＭＭ
２３（２３Ａ〜２３Ｃ） ゲストＯＳ
２４（２４Ａ〜２４Ｃ） コンテナランタイム
２５ ストレージソフトウェア
２６ 管理ソフトウェア
２７ コンピューティングソフトウェア
１００ 管理コントローラ
２００ モニタ
３００ ボリュームクラシファイア
４００ リソースクラシファイア
５００ リバランサ
１２１ ノード構成テーブル
１２２ ボリューム負荷テーブル
１２３ ノード負荷テーブル
１２４ グループサイクルテーブル
１２５ ボリュームグループテーブル
１２６ ボリューム配置テーブル
１２７ モニタ頻度テーブル
１２８ リソースキャパシティテーブル

Claims (13)

  1. 互いにネットワークで接続され、プロセッサとメモリとを有して、上位システムがデータを入出力する複数のボリュームを提供する複数のノードと、
    前記ボリュームに入出力されるデータを格納する記憶媒体と、
    を備えた分散型ストレージシステムにおいて、
    前記複数のボリュームは、各ボリュームにおける負荷の変動周期に基づいて、複数のグループに分類されており、
    前記プロセッサは、前記グループ内の同じノード上の複数のボリュームの負荷を時間ごとに合計した合計負荷を算出するとともに、合計負荷のピークに基づいて、グループ負荷を算出し、
    何れかのノードの前記プロセッサは、前記ノード間でボリュームを移動させるリバランスにおける移動候補のボリュームを移動元ノードから移動先ノードに移動させた場合の前記移動先ノードの前記グループ負荷を算出し、前記算出した移動先ノードのグループ負荷に基づいて、前記リバランスにおける移動するボリュームと移動先ボリュームとを決定し、前記リバランスを実行する
    ことを特徴とする分散型ストレージシステム。
  2. 前記プロセッサは、
    前記合計負荷のピークのうち最大のピークに基づいて、前記グループ負荷を算出する
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  3. 各々の前記ノードは、
    そのリソースを、前記グループ負荷に基づいて、自ノード上の前記グループごとに割当てており、
    前記グループ負荷が変化した場合に、前記リソースの割当変更及び前記リバランスを行う
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  4. 前記負荷の周期に基づくグループへの分類は、各ボリュームの負荷を正弦波の成分に分解し、正弦波の成分の周期うち最も長い周期に基づいて、分類する
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  5. 前記グループへの分類に用いる周期は、あらかじめ決められた所定の周期であり、
    前記所定の周期は、１日、１週、１月、及び１年を含み
    これらの内の最も長い変動周期に基づいて、分類する
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  6. 何れかのノードの前記プロセッサは、移動候補のボリュームを移動させた場合の前記移動先ノードの前記グループ負荷の増加量に基づいて、前記移動先ノードを選択する
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  7. 何れかのノードの前記プロセッサは、
    移動元のノードの対象グループから移動候補のボリュームを選択し、
    移動候補のボリュームを移動元ノードから移動先ノードに移動させた場合の前記移動先ノードの前記グループ負荷を算出して、移動が適切と判断した場合に移動を決定し、
    前記移動候補のボリュームの選択と、移動の決定とを、移動後の負荷が所定の条件を満たすまで繰り返す
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  8. 前記移動候補のボリュームとして、負荷の大きいボリュームから選択し、
    前記移動候補のボリュームを移動後の前記移動元ノードのグループ負荷が所定値より小さくなった場合に、前記移動候補のボリュームの選択を終了する
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  9. 前記負荷は、複数種類の負荷を含み、
    前記グループ負荷を算出するための最大のピークは、負荷の種類ごとに異なる時間の負荷を用いることができる
    ことを特徴とする請求項２に記載の分散型ストレージシステム。
  10. 前記負荷は、複数種類の負荷を含み、
    前記グループ負荷を算出するための最大のピークは、複数種類の負荷の合計のピークである
    ことを特徴とする請求項２に記載の分散型ストレージシステム。
  11. 前記負荷は、プロセッサの負荷、メモリの負荷、前記複数のノードを接続するネットワークの負荷を含む
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  12. 前記記憶媒体は、前記複数のノードがそれぞれ有しており、
    前記負荷は、記憶媒体の負荷をさらに含む
    ことを特徴とする請求項１に記載の分散型ストレージシステム。
  13. 互いにネットワークで接続され、プロセッサとメモリとを有して、上位システムがデータを入出力する複数のボリュームを提供する複数のノードと、前記ボリュームに入出力されるデータを格納する記憶媒体と、を有する分散型ストレージシステムによるリバランス処理方法において、
    前記複数のボリュームは、各ボリュームにおける負荷の変動周期に基づいて、複数のグループに分類されており、
    前記プロセッサが、前記グループ内の同じノード上の複数のボリュームの負荷を時間ごとに合計した合計負荷を算出するとともに、合計負荷のピークに基づいて、グループ負荷を算出し、
    何れかのノードの前記プロセッサが、前記ノード間でボリュームを移動させるリバランスにおける移動候補のボリュームを移動元ノードから移動先ノードに移動させた場合の前記移動先ノードの前記グループ負荷を算出し、前記算出した移動先ノードのグループ負荷に基づいて、前記リバランスにおける移動するボリュームと移動先ボリュームとを決定し、前記リバランスを実行する
    ことを特徴とするリバランス処理方法。
JP2020104544A 2020-06-17 2020-06-17 分散型ストレージシステム及びリバランス処理方法 Pending JP2021197010A (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2020104544A JP2021197010A (ja) 2020-06-17 2020-06-17 分散型ストレージシステム及びリバランス処理方法
US17/200,417 US20210397485A1 (en) 2020-06-17 2021-03-12 Distributed storage system and rebalancing processing method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020104544A JP2021197010A (ja) 2020-06-17 2020-06-17 分散型ストレージシステム及びリバランス処理方法

Publications (1)

Publication Number Publication Date
JP2021197010A true JP2021197010A (ja) 2021-12-27

Family

ID=79022523

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020104544A Pending JP2021197010A (ja) 2020-06-17 2020-06-17 分散型ストレージシステム及びリバランス処理方法

Country Status (2)

Country Link
US (1) US20210397485A1 (ja)
JP (1) JP2021197010A (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022187285A (ja) * 2021-06-07 2022-12-19 富士通株式会社 管理装置，ストレージシステム及び情報処理方法

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4469252B2 (ja) * 2004-10-19 2010-05-26 株式会社日立製作所 ストレージネットワークシステム及びホスト計算機並びに物理パス割当方法
JP5228988B2 (ja) * 2009-02-23 2013-07-03 富士通株式会社 割当制御プログラム及び割当制御装置
US8935500B1 (en) * 2009-09-24 2015-01-13 Vmware, Inc. Distributed storage resource scheduler and load balancer
US8539197B1 (en) * 2010-06-29 2013-09-17 Amazon Technologies, Inc. Load rebalancing for shared resource
JP2017228881A (ja) * 2016-06-21 2017-12-28 富士通株式会社 ネットワーク評価プログラム、ネットワーク評価方法、及び、ネットワーク評価装置
US11068315B2 (en) * 2018-04-03 2021-07-20 Nutanix, Inc. Hypervisor attached volume group load balancing
JP2019219954A (ja) * 2018-06-20 2019-12-26 株式会社日立製作所 クラスタストレージシステム、データ管理制御方法、データ管理制御プログラム

Also Published As

Publication number Publication date
US20210397485A1 (en) 2021-12-23

Similar Documents

Publication Publication Date Title
US10922269B2 (en) Proactive optimizations at multi-tier file systems
CN110301128B (zh) 基于学习的资源管理数据中心云架构的实现方法
Zhang et al. Faster and cheaper serverless computing on harvested resources
Ghomi et al. Load-balancing algorithms in cloud computing: A survey
Hernández et al. Using machine learning to optimize parallelism in big data applications
US11720408B2 (en) Method and system for assigning a virtual machine in virtual GPU enabled systems
US11693698B2 (en) System and method for infrastructure scaling
US10956230B2 (en) Workload placement with forecast
JP2021056955A (ja) 分散型ストレージシステム及びデータ移動方法
Taft et al. P-store: An elastic database system with predictive provisioning
US8024542B1 (en) Allocating background workflows in a data storage system using historical data
US11409453B2 (en) Storage capacity forecasting for storage systems in an active tier of a storage environment
US20220229707A1 (en) Managing migration of workload resources
Gandomi et al. HybSMRP: a hybrid scheduling algorithm in Hadoop MapReduce framework
Ma et al. Dependency-aware data locality for MapReduce
Yu et al. Cloud task scheduling algorithm based on three queues and dynamic priority
Sellami et al. Clustering-based data placement in cloud computing: a predictive approach
Lu et al. InSTechAH: Cost-effectively autoscaling smart computing hadoop cluster in private cloud
Li et al. Cost-efficient scheduling algorithms based on beetle antennae search for containerized applications in Kubernetes clouds
Peng et al. Research on application classification method in cloud computing environment
US20210397485A1 (en) Distributed storage system and rebalancing processing method
You et al. Ursa: Scalable load and power management in cloud storage systems
Heidari et al. A cost-efficient auto-scaling algorithm for large-scale graph processing in cloud environments with heterogeneous resources
Ehsan et al. Cost-efficient tasks and data co-scheduling with affordhadoop
Ravandi et al. A self-organized resource provisioning for cloud block storage