JPWO2018109816A1 - データリバランスを制御するシステムおよび方法 - Google Patents

Abstract

データリバランス制御システムは、計算機システムに含まれる１以上の計算機に接続され圧縮機能を有する記憶デバイスを少なくとも１つ含んだ複数の記憶デバイスに対応した複数の物理容量を示す情報を含んだ容量情報を基に、リバランス機能を有するエンティティに対する指示内容を決定する。エンティティのリバランス機能は、複数の記憶デバイスに対応し当該エンティティが認識する複数の論理容量の配分を決められた配分となるようデータをリバランスする機能である。決定された指示内容は、論理容量配分に関する定義を含む。そのような指示内容に従いデータをリバランスすることの指示であるリバランス指示を、データリバランス制御システムがエンティティに送信する。

Description

本発明は、データリバランスの制御に関する。

一般に、ＩＴインフラには高いコスト対効果が求められている。記憶デバイスのビットコストを低減させる効果のあるデータ圧縮技術は、今後普及していくと考えられる。

また、近年、スモールスタートおよびスケールアウトが容易である分散アプリケーションの市場は拡大している。分散アプリケーションとしては、データを複数のサーバに分散して格納するアプリケーションがある。

データの格納が特定サーバに集中して、容量不足が生じることで、書き込み失敗が発生するおそれがある。

例えば、特許文献１によれば、単一のストレージ装置において、圧縮機能を有する記憶デバイス間で、データがリバランスされる。

WO2014/184941

以下の説明では、記憶デバイスの実際の記憶容量を「物理記憶容量」と言い、記憶デバイスに実際に格納されているデータの総量を「物理使用容量」と言い、物理記憶容量と物理使用容量との差分を「物理残容量」と言う。一方、記憶デバイスが提供する論理記憶空間の記憶容量を「論理記憶容量」と言い、論理記憶空間に格納されているデータの総量を「論理使用容量」と言い、論理記憶容量と論理使用容量との差分を「論理残容量」と言う。

また、以下の説明では、物理使用容量、物理残容量、物理残割合（物理記憶容量に対する物理残容量の割合）、および、物理使用割合（物理記憶容量に対する物理使用容量の割合）のいずれかを意味することを「物理容量」と総称し、論理使用容量、論理残容量、論理残割合（論理記憶容量に対する論理残容量の割合）、および、論理使用割合（論理記憶容量に対する論理使用容量の割合）のいずれかを意味することを「論理容量」と総称することがある。

記憶デバイスが圧縮機能を持つ場合、アプリケーションが認識するデータ量は、記憶デバイスに格納される圧縮済のデータ量と異なる。結果として、アプリケーションが認識する使用容量（論理使用容量）または残容量（論理残容量）は、物理使用容量または物理残容量と異なる。

アプリケーション（例えば分散アプリケーション）として、リバランス機能を有するアプリケーションが知られている。しかし、そのようなアプリケーションは、一般に、そのアプリケーションが認識する論理容量が平準化するようデータを記憶デバイス間でリバランスするようになっている。このため、論理容量が平準化しても、物理容量は平準化しない。

特許文献１の技術を利用すれば、物理容量の平準化が期待される。しかし、上述したように、リバランス機能を有するアプリケーションは、一般に、そのアプリケーションが認識する論理容量が平準化するようデータをリバランスするようになっている。このため、物理容量が一旦平準化したとしても、アプリケーションが論理容量が平準化するようデータをリバランスしてしまうため、物理容量の平準化の維持が困難であると考えられる。

このような問題は、論理容量が平準化するようデータをリバランスするようになっているリバランス機能が実行され得る他の環境についてもあり得る。

データリバランス制御システムは、計算機システムに含まれる１以上の計算機に接続され圧縮機能を有する記憶デバイスを少なくとも１つ含んだ複数の記憶デバイスに対応した複数の物理容量を示す情報を含んだ容量情報を基に、リバランス機能を有するエンティティに対する指示内容を決定する。エンティティのリバランス機能は、複数の記憶デバイスに対応し当該エンティティが認識する複数の論理容量の配分を決められた配分となるようデータをリバランスする機能である。決定された指示内容は、論理容量配分に関する定義を含む。そのような指示内容に従いデータをリバランスすることの指示であるリバランス指示を、データリバランス制御システムがエンティティに送信する。

本発明により、エンティティのリバランス機能が決められた論理容量配分通りにデータをリバランスしても特定の記憶デバイスの物理残容量が不足しないことを期待できる。

第一の実施例に係る情報システムの全体構成を示すブロック図。 図１に示した計算機および記憶デバイスの構成を示すブロック図。 図１に示したマネージャの構成を示すブロック図。 図３に示したリバランス優先度テーブルの一例を示す模式図。 図３に示した枯渇条件テーブルの一例を示す模式図。 図３に示したノード容量テーブルの一例を示す模式図。 テーブル設定処理のフローチャート。 容量監視処理のフローチャート。 リバランス制御処理のフローチャート。 第二の実施例に係る情報システムの構成を示すブロック図。 第二の実施例に係る計算機の構成を示すブロック図。 アプリ別リバランス優先度テーブルの一例を示す模式図。 アプリ別枯渇条件テーブルの一例を示す模式図。 リバランス宣言処理のフローチャート。 第三の実施例に係る計算機の構成を示すブロック図。 第四の実施例に係る計算機の構成を示すブロック図。 第五の実施例に係る情報システムの全体構成を示すブロック図。

以下の説明では、「アプリ」とは、アプリケーションプログラムの略である。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号を使用し、同種の要素を区別する場合は、要素のＩＤを使用することがある。例えば、アプリを区別しない場合には、「アプリ２１２」と言い、アプリを区別する場合には、「アプリａ１」、「アプリａ２」、「アプリａ３」のように言う。

また、以下の説明では、「インターフェース部」は、１以上のインターフェースを含む。１以上のインターフェースは、１以上の同種のインターフェースデバイス（例えば１以上のＮＩＣ（Network Interface Card））であってもよいし２以上の異種のインターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「記憶部」は、１以上のメモリを含む。少なくとも１つのメモリは、揮発性メモリであってもよいし不揮発性メモリであってもよい。記憶部は、主に、プロセッサ部による処理の際に使用される。

また、以下の説明では、「プロセッサ部」は、１以上のプロセッサを含む。少なくとも１つのプロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサである。１以上のプロセッサの各々は、シングルコアでもよいしマルチコアでもよい。プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。

また、以下の説明では、「ｘｘｘテーブル」といった表現にて情報を説明することがあるが、情報は、どのようなデータ構造で表現されていてもよい。すなわち、情報がデータ構造に依存しないことを示すために、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

また、以下の説明では、「計算機システム」は、１以上の物理的な計算機を含む。少なくとも１つの物理的な計算機が、仮想的な計算機（例えばＶＭ（Virtual Machine））を実行してもよいし、ＳＤｘ（Software-Defined anything）を実行してもよい。ＳＤｘとしては、例えば、ＳＤＳ（Software Defined Storage）（仮想的なストレージ装置の一例）またはＳＤＤＣ（Software-defined Datacenter）を採用することができる。

また、以下の説明では、「管理システム」は、一以上の計算機で構成されてよい。具体的には、例えば、管理計算機が表示デバイスを有していて管理計算機が自分の表示デバイスに情報を表示する場合、管理計算機が管理システムでよい。また、例えば、管理計算機（例えばサーバ）が表示用情報を遠隔の表示用計算機（例えばクライアント）に送信し表示用計算機がその情報を表示する場合（管理計算機が表示用計算機に情報を表示する場合）、管理計算機と表示用計算機とのうちの少なくとも管理計算機を含んだシステムが管理システムでよい。管理システムは、インターフェース部、記憶部およびそれらに接続されたプロセッサ部を有してよい。インターフェース部は、ユーザインターフェース部と、通信インターフェース部とのうちの少なくとも１つを含んでよい。ユーザインターフェース部は、１以上のＩ／Ｏデバイス（例えば入力デバイス（例えばキーボードおよびポインティングデバイス）と出力デバイス（例えば表示デバイス））と表示用計算機とのうちの少なくとも１つのＩ／Ｏデバイスを含んでよい。通信インターフェース部は、１以上の通信インターフェースデバイスを含んでよい。管理システムにおける計算機が「表示用情報を表示する」ことは、計算機が有する表示デバイスに表示用情報を表示することであってもよいし、計算機が表示用計算機に表示用情報を送信することであってもよい（後者の場合は表示用計算機によって表示用情報が表示される）。

また、以下の説明では、「ｋｋｋ部」の表現にて処理部（機能）を説明することがあるが、処理部は、１以上のコンピュータプログラムがプロセッサ部によって実行されることで実現されてもよいし、１以上のハードウェア回路（例えばＦＰＧＡまたはＡＳＩＣ（Application Specific Integrated Circuit））によって実現されてもよい。プログラムがプロセッサ部によって処理部が実現される場合、定められた処理が、適宜に記憶資源（例えばメモリ）および／または通信インターフェイスデバイス（例えば通信ポート）等を用いながら行われるため、処理部はプロセッサ部の少なくとも一部とされてもよい。処理部を主語として説明された処理は、プロセッサ部あるいはそのプロセッサ部を有する装置が行う処理としてもよい。また、プロセッサ部は、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースからプロセッサにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各処理部の説明は一例であり、複数の処理部が１つの処理部にまとめられたり、１つの処理部が複数の処理部に分割されたりしてもよい。

また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部およびインターフェース部のうちの少なくとも１つを用いながら行うため、処理の主語が、プロセッサ部（或いは、プロセッサ部を有する計算機）とされてもよい。プログラムは、プログラムソースから計算機にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明では、管理システムと計算機（計算機システムにおける少なくとも１つの計算機）とのうちの少なくとも１つが、データリバランス制御システムの一例である。データリバランス制御システムは、管理システムと、計算機システムにおける少なくとも１つの計算機とのうちの少なくとも１つとを含んでよい。

また、以下の説明では、「物理容量」は、典型的には物理残容量を意味し、「論理容量」は、典型的には論理残容量を意味するものとする。

以下、図面を参照して、本発明の幾つかの実施例を説明する。

図１は、第一の実施例に係る情報システムの全体構成を示す。

情報システムは、管理システム１６１、ホストシステム１６２、計算機システム、および、複数の記憶デバイス１０１を含む。管理システム１６１、ホストシステム１６２および計算機システムが、ネットワーク１０４を介して通信することができる。ネットワーク１０４は、例えばＩＰ（Internet Protocol）ネットワークである。

管理システム１６１は、マネージャ１０３を実行する。

ホストシステム１６２は、１以上のホスト計算機であり、１以上のアプリ２１２（例えばアプリａ２）を実行する。

計算機システムは、１以上の計算機１０２（例えば計算機ＡおよびＢ）を含む。１以上の計算機１０２には、１以上の記憶デバイス１０１（例えば記憶デバイスＡ〜Ｃ）が接続される。１以上の計算機１０２は、記憶デバイス１０１と同数のノード１１１（例えばノードｎ１〜ｎ３）を有する。ノード１１１は、計算機１０２において実行されるコンピュータプログラムの一例でよい。ノード１１１と記憶デバイス１０１は、一対一で対応するものとする。すなわち、ノードｎ１〜ｎ３は、それぞれ、記憶デバイスＡ〜Ｃに対応するものとする。

また、１以上の計算機１０２のうちの少なくとも１つにおいて、アプリ２１２が実行される。例えば、計算機Ａにおいて、アプリａ１が実行され、計算機Ｂにおいて、アプリａ３が実行されるとする。アプリ２１２は、Ｗｅｂアプリケーションでもよいし、ミドルウェアでもよいし、ＯＳ（Operating System）でもよい。少なくとも１つの計算機１０２において、ノード１１１以外のコンピュータプログラムのうちの少なくとも１つが、アプリ２１２に該当し得る。本実施例では、アプリａ１〜ａ３のうちの少なくともアプリａ１またはａ３が、分散アプリケーションでよい。具体的には、例えば、記憶デバイスＡ〜Ｃがそれぞれ提供する論理記憶空間を、アプリａ１およびａ３のうちの少なくとも１つが認識していてよく、アプリａ１およびａ３の少なくとも１つが、複数の論理記憶空間の間において論理容量（当該アプリが認識する論理容量）の配分が決められた配分となるようにデータをリバランスするリバランス機能を有していてよい。

図２は、記憶デバイス１０１と計算機１０２の構成を示す。

１以上の記憶デバイス１０１のうちの少なくとも１つが圧縮機能を有するが、本実施例では、各記憶デバイス１０１が、圧縮機能２８９を有する。

記憶デバイス１０１は、記憶媒体２０１と、記憶媒体２０１に対するデータのＩ／Ｏ（Input/Output）を制御するコントローラであるデバイスコントローラ２８２とを有する。

各記憶デバイス１０１は、典型的には、物理的な不揮発性の記憶デバイスであり、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）である。このため、記憶媒体２０１は、例えば、ハードディスクまたはフラッシュメモリ（１以上のフラッシュメモリチップ）である。本実施例では、各記憶デバイス１０１は、ＳＳＤであるとする。

デバイスコントローラ２８２は、記憶媒体２０１に接続されている。また、デバイスコントローラ２８２は、計算機１０２に接続される。デバイスコントローラ２８２は、例えば、プロセッサやメモリといった計算機リソースを有してよい。デバイスコントローラ２８２は、計算機１０２からＩ／Ｏコマンドを受け付け、そのＩ／Ｏコマンドに従い、記憶媒体２０１に対するデータのライトまたはリードを実行する。デバイスコントローラ２８２は、記憶媒体２０１の物理記憶容量、物理使用容量および物理残容量を管理できる。デバイスコントローラ２８２は、記憶媒体２０１に基づく論理記憶空間を計算機１０２に提供できる。デバイスコントローラ２８２は、圧縮機能２８９を有する。また、圧縮機能２８９は、コンピュータプログラムがプロセッサにより実行されることによって実現されてもよいし、ハードウェア回路（例えばＡＳＩＣ（Application Specific Integrated Circuit）またはＦＰＧＡ（Field-Programmable Gate Array））として実現されてもよい。

計算機１０２は、ＦＥ Ｉ／Ｆ（フロントエンドインターフェースデバイス）２５６、ＢＥ Ｉ／Ｆ（バックエンドインターフェースデバイス）２５８、メモリ２５２、およびそれらに接続されたプロセッサ２５１を有する。

ＦＥ Ｉ／Ｆ２５６は、ネットワーク１０４に接続される。ＢＥ Ｉ／Ｆ２５８は、記憶デバイス１０１のデバイスコントローラ２８２に接続される。ＦＥ Ｉ／Ｆ２５６およびＢＥ Ｉ／Ｆ２５８が、インターフェース部の一例である。

メモリ２５２は、記憶部の一例であり、ノード１１１と１以上のアプリ２１２を格納する。ノード１１１およびアプリ２１２が、プロセッサ２５１によって実行される。

ノード１１１は、そのノード１１１に対応した記憶デバイス１０１の論理記憶空間を、そのノード１１１を実行する計算機１０２内のアプリ２１２に提供する。ノード１１１は、そのノード１１１に対応した記憶デバイス１０１の論理記憶空間を、そのノード１１１を実行する計算機１０２外のアプリ２１２に提供してもよい。ノード１１１は、論理記憶空間に対するＩ／Ｏ要求を受け付け、そのＩ／Ｏ要求に従い、そのノード１１１に対応する記憶デバイス１０１に対してデータのライトまたはリードを実行する（Ｉ／Ｏコマンドを記憶デバイス１０１に送信する）。ノード１１１は、その対応する記憶デバイス１０１に対するライト対象のデータ（ライト対象データのＩ／Ｏ要求）を、例えばデータの冗長性維持のために、他記憶デバイス１０１に接続されているノード１１１（例えば、他計算機１０２内のノード１１１）に転送することができる。転送されたライト対象データは他記憶デバイス１０１に格納されてよい。ノード１１１は、例えばＳＤＳ（Software Defined Storage）でよい。ノード１１１は、ストレージサービス２２１を有する。

ストレージサービス２２１は、Ｉ／Ｏ要求を受け付けそのＩ／Ｏ要求に従い記憶デバイス１０１に対してデータのライトまたはリードを実行する仮想的なコントローラである仮想的なストレージコントローラに相当する。つまり、ストレージサービス２２１、または、ストレージサービス２２１を含んだノード１１１が、ストレージ制御機能の一例である。ストレージサービス２２１は、容量監視機能２３１、容量通知機能２３２、およびリバランス機能２３３を有する。容量監視機能２３１は、この機能２３１を含んだノード１１１に対応する記憶デバイス１０１の論理容量および物理容量を監視する（例えば定期的にチェックする）。容量通知機能２３２は、容量監視機能２３１により特定された論理容量および物理容量をマネージャ１０３に通知する。リバランス機能２３３は、データをリバランスする。

アプリ２１２は、リバランス機能２４１を有する。リバランス機能２４１は、データをリバランスする。

リバランス機能２３３および２４１は、同一の機能であっても異なる機能であってもよい。後者の場合、リバランス機能２３３は、第１のリバランス方法に従うリバランスを実行し、リバランス機能２４１は、第２のリバランス方法に従うリバランスを実行してもよい。リバランス機能２３３および２４１のうちの少なくともリバランス機能２４１（アプリ２１２が有するリバランス機能２４１）は、アプリ２１２が物理容量を把握することは通常できないため、そのリバランス機能２４１に定義されている論理容量配分通りに（例えば論理容量が平準化するように）データをリバランスするようになっている。

図３は、管理システム１６１の構成を示す。

管理システム１６１は、入力デバイス３５５、出力デバイス３５６、Ｉ／Ｆ（インターフェースデバイス）３５８、メモリ３５２、およびそれらに接続されたプロセッサ３５１を有する。

入力デバイス３５５、例えばキーボードおよびポインティングデバイスである。出力デバイス３５６は、例えば液晶ディスプレイのような表示デバイスである。入力デバイス３５５および出力デバイス３５６が、例えばタッチパネルのように一体であってもよい。

Ｉ／Ｆ３５８は、ネットワーク１０４に接続される。Ｉ／Ｆ３５８が、インターフェース部の一例である。

メモリ３５２は、記憶部の一例であり、マネージャ１０３を格納する。マネージャ１０３が、プロセッサ３５１によって実行される。

マネージャ１０３は、リバランス機能（例えばアプリのようなエンティティ）とストレージ制御機能（本実施例ではストレージサービス２２１）とを連携するリバランス制御機能の一例である。ここで言う「連携」とは、容量（論理容量および物理容量）を表す情報を含んだ容量情報をストレージ制御機能から受信することと、受信した容量に基づきリバランス指示をリバランス機能に対して送信することを意味する。これにより、物理容量を把握できないエンティティが行うリバランスを物理容量に基づいて制御することができる。マネージャ１０３は、テーブル設定機能３０１、容量受信機能３０２、枯渇検知機能３０３、リバランス選択機能３０４およびリバランス指示機能３０５を有する。また、マネージャ１０３は、リバランス優先度テーブル３０６、枯渇条件テーブル３０７およびノード容量テーブル３０８を管理する。

テーブル設定機能３０１は、テーブル３０６〜３０８の設定および更新を行う。容量受信機能３０２は、記憶デバイス１０１の論理容量および物理容量を表す情報である容量情報をノード１１１から受信する。枯渇検知機能３０３は、容量枯渇を検知する。リバランス選択機能３０４は、リバランス機能を選択する。リバランス指示機能３０５は、選択されたリバランス機能に対するリバランス実施を指示する。

以下、リバランス優先度テーブル３０６、枯渇条件テーブル３０７およびノード容量テーブル３０８を説明する。

図４Ａは、リバランス優先度テーブル３０６の一例を示す。

リバランス優先度テーブル３０６は、リバランス機能に関する情報を保持する。リバランス優先度テーブル３０６は、リバランス機能毎に、リバランス機能を識別するＩＤであるリバランスＩＤ４２１と、当該リバランス機能を持つアプリを識別するＩＤであるアプリＩＤ４２２と、当該リバランス機能の優先度を示す優先度４２３といった情報を保持する。本実施例では、優先度４２３の値が小さいほど、高い優先度となる。また、リバランス機能を有する対象がストレージサービス２２１の場合、ストレージサービス２２１のＩＤがアプリＩＤとして登録されてもよい。

例えば、１番目の行によれば、リバランス機能ｒ１（リバランスＩＤ“ｒ１”で識別されるリバランス機能）の優先度が“２”であり、アプリａ２およびａ３（アプリＩＤ“ａ２”および“ａ３”でそれぞれ識別されるアプリ２１２）の各々がリバランス機能ｒ１を有している。また、１番目の行と２番目の行によれば、アプリａ１とアプリａ３が動作しているノードでリバランスを実施する場合、アプリａ３が有するリバランス機能ｒ１の優先度が“２”であり、アプリａ１が有するリバランス機能ｒ２の優先度が“１”であることから、優先度が“１”であるアプリａ１のリバランス機能ｒ２を優先的に実施する。

図４Ｂは、枯渇条件テーブル３０７の一例を示す。

枯渇条件テーブル３０７は、枯渇条件に関する情報を保持する。枯渇条件テーブル３０７は、ノード１１１毎に、ノード１１１を識別するＩＤであるノードＩＤ４３１と、当該ノード１１１に対応する記憶デバイス１０１にデータを格納するアプリ２１２と当該アプリ２１２がデータを格納する記憶デバイス１０１に対応するノード１１１の一覧を示すアプリ稼働４３２と、当該ノード１１１に対応する記憶デバイス１０１の容量枯渇の定義である枯渇条件を示す枯渇条件４３３といった情報を保持する。アプリ稼働４３２は、アプリＩＤと、当該アプリＩＤに対応したアプリのデータ格納先である記憶デバイス１０１に対応するノード１１１を識別するノードＩＤとの組合せである。

例えば、１番目の行によれば、ノードｎ１（ノード識別子“ｎ１”で識別されるノード１１１）に対応する記憶デバイス１０１には、アプリａ１およびアプリａ３がデータを格納するようになっている。当該記憶デバイス１０１にデータを格納するアプリａ１は、ノードｎ１、ノードｎ２、ノードｎ３に対応する記憶デバイス１０１にもデータを格納する。また、当該記憶デバイス１０１にデータを格納するアプリａ２は、ノードｎ１、ノードｎ２、ノードｎ３に対応する記憶デバイス１０１にもデータを格納する。ノードｎ１に対応する記憶デバイス１０１は、当該記憶デバイス１０１の物理残容量が１０ＧＢ未満であり、かつ、物理残容量が論理残容量未満である場合に、容量枯渇と判断される。

なお、「論理容量」とは、論理使用容量又は論理残容量であり、アプリ２１２が認識する容量である。「物理容量」とは、物理使用容量又は物理残容量であり、記憶デバイス１０１が認識する容量である。アプリ２１２が記憶デバイス１０１に格納するデータは、記憶デバイス１０１の圧縮機能２８９により圧縮された後、その記憶デバイス１０１の記憶媒体２０１に格納される。つまり、論理使用容量は圧縮前の容量、物理使用容量は圧縮後の容量と言うこともできる。

枯渇条件は、複数の記憶デバイス１０１（複数のノード１１１）のうちの２以上の記憶デバイス１０１（２以上のノード１１１）について異なっていてもよい。つまり、記憶デバイス１０１によって異なる枯渇条件が採用されてもよい。枯渇条件は、リバランス実行要の条件の一例である。記憶デバイス１０１によって異なる枯渇条件が採用されることで、柔軟なデータリバランス、例えば、記憶デバイス１０１（ノード１１１）にとってより適切なタイミングでデータをリバランスすることが期待できる。

図４Ｃは、ノード容量テーブル３０８の一例を示す。

ノード容量テーブル３０８は、ノード１１１が管理する容量に関する情報を保持する。ノード容量テーブル３０８は、ノード１１１毎に、ノード１１１を識別するＩＤであるノードＩＤ４４１と、当該ノード１１１に対応する記憶デバイス１０１の論理記憶容量のうちの論理使用容量を示す論理使用容量４４２と、当該ノード１１１に対応する記憶デバイス１０１の論理記憶容量のうちの論理残容量を示す論理残容量４４３と、当該ノード１１１に対応する記憶デバイス１０１の物理記憶容量のうちの物理使用容量を示す物理使用容量４４４と、当該ノード１１１に対応する記憶デバイス１０１の物理記憶容量のうちの物理残容量を示す物理残容量４４５といった情報を保持する。

例えば、１番目の行によれば、ノードｎ１に対応する記憶デバイス１０１の論理記憶容量のうち、４００ＧＢが論理使用容量であり、２００ＧＢが論理残容量である。当該記憶デバイス１０１の物理記憶容量のうち、６０ＧＢが物理使用容量であり、１４０ＧＢが物理残容量である。

図４Ｃのノード容量テーブル３０８によれば、全ての記憶デバイス１０１の物理記憶容量は同じ（２００ＧＢ）であるが、物理記憶容量の異なる記憶デバイス１０１が混在していてもよい。

図５は、マネージャ１０３により実施されるテーブル設定処理のフローチャートである。本処理は、ユーザ（例えば管理者）により設定が更新される際に実施される。

テーブル設定機能３０１は、ユーザから、入力デバイス３５５経由で、アプリ２１２に関する情報（例えばアプリＩＤ）と、当該アプリ２１２が用いる記憶デバイス１０１に対応したノード１１１に関する情報（例えばノードＩＤ）との入力を受ける（ステップ５０１）。

テーブル設定機能３０１は、ユーザから、入力デバイス３５５経由で、ノード１１１について、そのノード１１１に対応した記憶デバイス１０１の枯渇条件に関する情報の入力を受ける（ステップ５０２）。

テーブル設定機能３０１は、ステップ５０１とステップ５０２で受けた情報を枯渇条件テーブル３０７に登録する、すなわち、枯渇条件テーブル３０７を更新する（ステップ５０３）。この際、記憶デバイス１０１とノード１１１は一対一で対応しているため、テーブル設定機能３０１は、記憶デバイス１０１に関する情報からノード１１１を一意に決定することができる。なお、枯渇条件４３３として初期値が予め登録されていてもよい（ステップ５０２がスキップされてもよい）。

テーブル設定機能３０１は、ユーザから、入力デバイス３５５経由で、アプリ２１２が有するリバランス機能２４１に関する情報（例えば、リバランスＩＤおよびアプリＩＤ）を受ける（ステップ５０４）。

テーブル設定機能３０１は、ユーザから、入力デバイス３５５経由で、リバランス機能２４１の優先度に関する情報（例えば優先度としての値）を受ける（ステップ５０５）。

テーブル設定機能３０１は、ステップ５０４とステップ５０５で受けた情報をリバランス優先度テーブル３０６に登録する、つまり、リバランス優先度テーブル３０６を更新する（ステップ５０６）。なお、アプリＩＤおよびリバランスＩＤは予めテーブル３０６に登録されていてもよい（ステップ５０４がスキップされてもよい）。

図６は、ストレージサービス２２１により実施される容量監視処理のフローチャートである。本処理は、例えば定期的に実施される。また、図６の説明において、ストレージサービス２２１を含んだノード１１１を「対象ノード１１１」と言う。

容量監視機能２３１は、対象ノード１１１に対応する記憶デバイス１０１に容量情報を要求する（ステップ６０１）。容量監視機能２３１は、記憶デバイス１０１から容量情報として、当該記憶デバイス１０１の論理使用容量、論理残容量、物理使用容量および物理残容量を示す情報を受信する（ステップ６０２）。

容量通知機能２３２は、ステップ６０２で容量監視機能２３１が受信した容量情報をマネージャ１０３に通知する（ステップ６０３）。

マネージャ１０３は、容量情報を受信する度に、次のような容量情報更新処理を実施する。すなわち、容量受信機能３０２は、受信した容量情報（論理使用容量、論理残容量、物理使用容量および物理残容量を示す情報）を、ノード容量テーブル３０８に登録する。

図７は、マネージャ１０３により実施されるリバランス制御処理のフローチャートである。本処理は例えば定期的に実施される。

枯渇検知処理を実施していないノードである未実施ノードがある場合（ステップ７０１：ＹＥＳ）、枯渇検知機能３０３は、当該未実施ノードに対応した記憶デバイスが容量枯渇しているか否かを、枯渇条件テーブル３０７とノード容量テーブル３０８を参照して判断する（ステップ７０２）。

例えば、図４Ｂの枯渇条件テーブル３０７において、ノードｎ１の枯渇条件から、当該ノードｎ１では、物理残容量が１０ＧＢ未満、かつ、物理残容量が論理残容量未満の時に枯渇と判断される。ノード容量テーブル３０８において、ノードｎ１の論理残容量は２００ＧＢであり、物理残容量は１４０ＧＢである。ノードｎ１の枯渇条件が満たされていないため、ノードｎ１については枯渇は検知されない。

ステップ７０２において、枯渇が検知されない場合（ステップ７０２：ＮＯ）、ステップ７０１に戻る。ステップ７０１において、全てのノードで枯渇検知処理が実施済みの場合（ステップ７０１：ＮＯ）、本リバランス制御処理が終了する。

また、例えば、枯渇条件テーブル３０７において、ノードｎ２の枯渇条件から、当該ノードｎ２では物理残容量が１０ＧＢ未満、かつ、物理残容量が論理残容量未満の時に枯渇と判断される。ノード容量テーブル３０８において、ノードｎ２の論理残容量は２００ＧＢであり、物理残容量は８ＧＢである。ノードｎ２の枯渇条件が満たされているため、ノードｎ２については枯渇が検知される。

ステップ７０２で、枯渇が検知される場合（ステップ７０２：ＹＥＳ）、リバランス選択機能３０４は、枯渇条件テーブル３０７とリバランス優先度テーブル３０６を参照してリバランス方法を検索する（ステップ７０３）。例えば、ステップ７０２でノードｎ２における枯渇が検知されている場合、リバランス選択機能３０４は、枯渇条件テーブル３０７のアプリ稼働４３２から、当該ノードｎ２に対応する記憶デバイス１０１にはアプリａ１とアプリａ３がデータを格納していることがわかる。また、リバランス優先度テーブル３０６から、アプリａ１はリバランス機能ｒ２が実施可能なこと、アプリａ３はリバランス機能ｒ１とリバランス機能ｒ３が実施可能とわかる。なお、当該リバランス制御処理において、当該ノードｎ２において当該アプリに対して実施済のリバランス機能は、本ステップにおける検索対象から除外する。このように枯渇が検知された場合にリバランス機能の検索へと進むので、枯渇が検知されないといったリバランス不要状況のときにまでリバランス機能を走らせることを避けることができる。

ステップ７０３で実施可能なリバランス機能が見つからない場合（ステップ７０３：ＮＯ）、リバランス選択機能３０４は、容量不足である警告をユーザに通知し（例えば警告を出力デバイス３５６に表示し）（ステップ７０４）、ステップ７０１に戻る。

ステップ７０３で実施可能なリバランス機能が見つかった場合（ステップ７０３：ＹＥＳ）、リバランス選択機能３０４は、リバランス優先度テーブル３０６を参照して、実施するリバランス機能を選択する（ステップ７０５）。例えば、ステップ７０３についての上述の例によれば、アプリａ３に対してリバランス機能ｒ１、アプリａ１に対してリバランス機能ｒ２、アプリａ３に対してリバランス機能ｒ３を実施することが可能である。リバランス優先度テーブル３０６の優先度４２３を参照すると、リバランス機能ｒ１の優先度は“２”、リバランス機能ｒ２の優先度は“１”、リバランス機能ｒ３の優先度は“３”であることがわかる。つまり、リバランス機能ｒ２の優先度が最も高いことがわかる。このため、リバランス選択機能３０４は、アプリａ１の有するリバランス機能ｒ２を選択する。このように、複数のリバランス機能を実施することが可能な場合には優先度の最も高いリバランス機能を優先することができる。

例えば、ステップ７０５で選択されたリバランス機能（例えば、当該リバランス機能を有するアプリ）は、典型的には、各ノード１１１（記憶デバイス１０１）に、そのノード１１１に対応した格納割合に従う量のデータを格納するようになっている。格納されるデータは、圧縮されていないデータである。つまり、ステップ７０５で選択されたリバランス機能は、典型的には、各ノード１１１に対応した論理容量が、そのリバランス機能に対して定義されている格納割合通りの論理容量となるように、データをリバランスするようになっている。

そこで、リバランス指示機能３０５は、ノード容量テーブル３０８を参照し、ステップ７０５で選択されたリバランス機能に対するリバランス指示の指示内容として、物理容量が平準化するような指示内容を決定する（ステップ７０６）。例えば、リバランス指示機能３０５は、ノード容量テーブル３０８を参照し、ステップ７０５で選択されたリバランス機能を実施するアプリがデータを格納しているノードに対応する記憶デバイスの圧縮率を、例えば当該ノードに対応した論理使用容量及び物理使用容量を基に算出し、現在各ノードへのデータを格納割合に、これら圧縮率の逆数を掛けあわせ、このようにして決定された格納割合の配分に関する定義を含んだ指示内容を決定してよい。あるいは、リバランス指示機能３０５は、最も圧縮率の低いノードへ（あるいは、例えば、最も物理残容量の少ないノード）の格納割合を一定数減らし、最も圧縮率の高いノード（あるいは、例えば、最も物理残容量の多いノード）への格納割合を一定数増やすことを意味する格納割合配分の定義を含んだ指示内容を決定してもよい。このように、リバランス指示に含まれる指示内容は、複数の物理容量が平準化するための論理容量配分に関する定義を含む。なお、「物理容量の平準化」は、複数の記憶デバイス１０１のうちの少なくとも１つの記憶デバイスの物理残容量が枯渇する（例えばゼロになる）ことを防ぐことの一例である。

リバランス指示機能３０５は、ステップ７０５で選択されたリバランス機能を持つアプリ２１２に、ステップ７０６で決定した指示内容に従いデータをリバランスすることの指示であるリバランス指示を送信する（ステップ７０７）。このリバランス指示に応答して、その指示を受けたアプリ２１２内のリバランス機能２４１が、そのリバランス指示に含まれる指示内容に従ってデータのリバランスを実施する。

なお、データのリバランスとは、典型的には、リバランス機能（リバランス指示を受けた機能）が、リバランス指示に従う変更後の配分（格納割合の比率）になるよう、ノード１１１間（記憶デバイス１０１間）でデータを移動することを含む。そのデータ移動に伴い、ノード１１１間で、論理容量の比率が、変更後の配分に近づき、結果として、物理容量が平準化していく。

リバランス機能２４１は、リバランスが終了した場合（例えば、指示内容に従う変更後の格納割合の比率と論理容量の比率との差が所定値以下になった場合）、リバランス終了をマネージャ１０３に返す。

リバランス指示機能７０９は、アプリ２１２（リバランス機能２４１）からリバランス終了の通知を受信する（ステップ７０８）。通知受信後、ステップ７０２に戻り、枯渇検知機能３０３は、当該ノードが容量枯渇のままか否かを判断する。この判断結果が偽の場合（ステップ７０２：ＮＯ）、つまり、当該ノードの容量枯渇が解消された場合、ステップ７０１に戻る。

以上が、第一の実施例についての説明である。本実施例によれば、マネージャ１０３が、記憶デバイス１０１の物理容量を監視するノード１１１と、定義された配分（格納割合）通りにデータをリバランスする（論理容量を制御する）リバランス機能（アプリ２１２）とを連携するようになっている。マネージャ１０３は、全てのノード１１１から物理容量を表す情報を取得し、全てのノード１１１の物理容量が平準化するように、リバランス機能が実施するリバランス（データ量の配分）を制御する。これにより、いずれのリバランス機能がそのリバランス機能に定義されている配分（格納割合）通りにデータをリバランスしても、物理容量の平準化を維持すること（言い換えれば、物理残容量の不足を避けること）が期待できる。

なお、図７のステップ７０６で決定される指示内容は、選択されたリバランス機能によって異なってよい。例えば、第１のリバランス機能については、指示内容は、物理残容量が不足し論理残容量に余裕のあるノードから一部の論理容量を確保すること、および、確保した論理容量を、物理残容量に余裕があり論理残容量が不足したノードに加えることを、含んでもよい。また、例えば、第２のリバランス機能については、指示内容は、物理残容量と比較して過剰に大きい論理残容量を有するノード以外のノードにその論理残容量を配分することを含んでもよいし、物理残容量が小さいノードの論理残容量を物理残容量が大きいノードの論理残容量に追加することを含んでもよい。

第二の実施例を説明する。その際、第一の実施例との相違点を主に説明し、第一の実施例との共通点については説明を省略又は簡略する。

図８は、第二の実施例に係る情報システムの全体構成を示す。

情報システムは、複数の記憶デバイス１０１と、複数の記憶デバイス１０１が接続される１以上の計算機８０２を含んだ計算機システムとを有する。なお、計算機８０２が１台の場合は、ネットワーク１０４は使用されないでよい。

１以上の計算機８０２は、複数の記憶デバイス１０１（例えば記憶デバイスＡ〜Ｃ）にそれぞれ対応した複数のノード１１１（例えばノードｎ１１、ｎ１２およびｎ１３）を有する。

第二の実施例は、マネージャが情報システムの構成に含まれない点、および、アプリが後述のアプリ別マネージャを有する点が、第一の実施例とは異なる。

図９は、第二の実施例に係る計算機８０２の構成を示す。

計算機８０２のメモリ２５２には、ノード９１１の他に、アプリ９１２が格納される。ノード９１１およびアプリ９１２が、プロセッサ２５１により実行される。

アプリ９１２は、リバランス機能２４１の他に、アプリ別マネージャ９０１を有する。

アプリ別マネージャ９０１は、テーブル設定機能３０１、リバランス指示機能３０５、枯渇検知機能３０３、容量受信機能３０２、リバランス宣言機能９２１、および、アプリ別リバランス選択機能９２５を有する。アプリ別マネージャ９０１は、ノード容量テーブル３０８、動作フラグ９２２、アプリ別リバランス優先度テーブル９２３、および、アプリ別枯渇条件テーブル９２４を管理する。

リバランス宣言機能９２１は、アプリ別マネージャ９０１を含んだアプリ９１２がリバランスを実施するか否かの宣言を実施する。

動作フラグ９２２は、例えば二値で示される。動作フラグ９２２は、当該アプリ別マネージャ９０１が動作するか否かを示す。つまり、アプリ９１２毎に、リバランス制御するか否かを制御することができる。

ノード９１１は、ストレージサービス９９９を有する。

ストレージサービス９９９は、容量監視機能２３１、容量通知機能２３２、リバランス機能２３３、および、アプリ別マネージャ９８１を有する。ストレージサービス９９９は、リバランスアプリ情報９８２を管理する。

アプリ別マネージャ９８１は、アプリ別マネージャ９０１と同様の機能を有する。

リバランスアプリ情報９８２は、アプリ別マネージャ９０１を含んだアプリ９１２のＩＤを含む。

計算機システムが複数の計算機８０２を有し、アプリ９１２が複数の計算機８０２で分散動作する場合がある。この時、アプリ別マネージャ９０１は、特定の計算機８０２上の代表アプリ９１２のみが有してもよいし、各アプリ９１２が有してアプリ９１２間で協調して動作してもよい。

本実施例では、代表アプリ９１２がアプリ別マネージャ９０１を有するとする。アプリ別マネージャ９０１が、アプリ別リバランス優先度テーブル９２３およびアプリ別枯渇条件テーブル９２４を管理する。

図１０Ａは、アプリ別リバランス優先度テーブル９２３の一例を示す。

アプリ別リバランス優先度テーブル９２３は、当該アプリ９１２の持つリバランス機能２４１毎に、当該リバランス機能２４１のＩＤであるリバランスＩＤ１０１１と、当該リバランス機能の優先度を示す優先度１０１２といった情報を保持する。

例えば、１番目の行によれば、リバランス機能ｒ１１の優先度が“１”である。故に、当該アプリ９１２のデータを格納しているノードで枯渇が発生した場合、リバランス機能ｒ１１が優先的に実施される。

図１０Ｂは、アプリ別枯渇条件テーブル９２４の一例を示す。

アプリ別枯渇条件テーブル９２４は、当該アプリ９１２のデータを格納している記憶デバイスに対応するノード毎に、当該ノードを識別するＩＤであるノードＩＤ１０２１と、当該ノードに対応した枯渇条件を示す枯渇条件１０２２といった情報を保持する。

例えば、１番目の行によれば、ノードｎ１１に対応する記憶デバイス１０１は、当該記憶デバイス１０１の物理残容量が１０ＧＢ未満であり、かつ、物理残容量が論理残容量未満である場合に、容量枯渇と判断される。

アプリ別マネージャ９０１は、テーブル設定処理を実施する。第二の実施例に係るテーブル設定処理は、図５に示したステップ５０１〜５０６に加えて（例えばステップ５０６実施後）、ユーザから当該アプリのリバランス機能の“動作”又は“非動作”を示す情報を受けて、その情報を動作フラグ９２２として登録（更新）することを含む。

図１１は、アプリ別マネージャ９０１により実施されるリバランス宣言処理のフローチャートである。本処理は、動作フラグ９２２の値が変更された際に実施される。

動作フラグ９２２が“１”（“動作”）に変更された場合（ステップ１１０１：“１”）、リバランス宣言機能９２１は、リバランスの実施の宣言、すなわち、ストレージサービス９９９のリバランスアプリ情報９８２に、当該アプリ９１２のアプリＩＤを登録する（ステップ１１０２）。

動作フラグ９２２が“０”（“非動作”）に変更された場合（ステップ１１０１：“０”）、リバランス宣言機能９２１は、リバランスの非実施の宣言、すなわち、ストレージサービス９９９のリバランスアプリ情報９８２から、当該アプリ９１２のアプリＩＤを削除する（ステップ１１０３）。

ストレージサービス９９９は、定期的に容量監視処理を実施する。第二の実施例に係る容量監視処理は、図６に示したステップ６０１およびステップ６０２を含む。ストレージサービス９９９は、ステップ６０２の実施により得られた容量情報を、リバランスアプリ情報９８２から識別されるアプリ２１２の有するアプリ別マネージャ９０１に通知する。

第二の実施例に係る容量情報更新処理は、第一の実施例と同様である。

アプリ別マネージャ９０１は、定期的にリバランス制御処理を実施する。第二の実施例に係るリバランス制御処理は、図７に示したステップ７０１、ステップ７０４、ステップ７０６、ステップ７０８、および、ステップ７０９を含む。

すなわち、ステップ７０１で、リバランス処理を未実施のノードを検知した場合、枯渇検知機能３０３は、その未実施のノードについて、アプリ別枯渇条件テーブル９２４とノード容量テーブル３０８を参照して、枯渇が生じているか否かを判断する。その判断結果が真の場合、アプリ別リバランス選択機能９２５は、アプリ別枯渇条件テーブル９２４とアプリ別リバランス優先度テーブル９２３を参照してリバランス機能を検索する。リバランス機能が見つかった場合、アプリ別リバランス選択機能９２５は、アプリ別リバランス優先度テーブル９２３を参照して、実施するリバランス機能を選択する。

リバランス機能選択後、ステップ７０６が実施される。ステップ７０６実施後、リバランス指示機能３０５は、選択したリバランス機能に、ステップ７０６で決定した指示内容を含んだリバランス指示を出す。

第二の実施例では、アプリ別マネージャ９０１が、記憶デバイス１０１の物理容量を監視するノード９１１と、定義された配分（格納割合）通りにデータをリバランスする（論理容量を制御する）リバランス機能とを連携するようになっている。アプリ別マネージャ９０１は、全てのノード９１１から物理容量を表す情報を取得し、全てのノード９１１の物理容量が平準化するように、リバランス機能が実施するリバランス（データ量の配分）を制御する。これにより、いずれのリバランス機能がそのリバランス機能に定義されている配分（格納割合）通りにデータをリバランスしても、物理容量の平準化を維持すること（言い換えれば、物理残容量の不足を避けること）が期待できる。

第三の実施例を説明する。その際、第一および第二の実施例のうちの少なくとも１つとの相違点を主に説明し、第一および第二の実施例のうちの少なくとも１つとの共通点については説明を省略又は簡略する。

第三の実施例は、マネージャが構成に含まれない点、アプリがアプリ別マネージャを有さない点、および、ストレージサービスが後述のストレージサービス別マネージャを有する点が、第一および第二の実施例と異なる。

図１２は、第三の実施例に係る計算機１２０２の構成を示す。

計算機１２０２のメモリ２５２には、アプリ２１２とノード１２１１が格納される。

ノード１２１１は、ストレージサービス１２２１を有する。

ストレージサービス１２２１は、容量監視機能２３１、容量通知機能２３２、リバランス機能２３３、および、ストレージサービス別マネージャ１２０１を有する。

ストレージサービス別マネージャ１２０１は、テーブル設定機能３０１、容量受信機能３０２、枯渇検知機能３０３、リバランス選択機能３０４、および、リバランス指示機能３０５を有する。ストレージサービス別マネージャ１２０１は、リバランス優先度テーブル３０６、枯渇条件テーブル３０７、および、ノード容量テーブル３０８を管理する。

計算機システムは、複数のノード１２１１を有するため、計算機システムは、複数のストレージサービス１２２１を有する。ストレージサービス別マネージャ１２０１は、代表ストレージサービス１２２１のみが有してもよいし、各ストレージサービス１２２１が有しストレージサービス１２２１間で協調して動作してもよい。本実施例では、代表ストレージサービス１２２１がストレージサービス別マネージャ１２０１を有するものとする。

第三の実施例に係るテーブル設定処理、容量情報更新処理、および、リバランス制御処理は、第一の実施例に係る処理と同様である。ただし、これらの処理はマネージャ１０３ではなく、ストレージサービス別マネージャ１２０１によって実施される。

ストレージサービス１２２１は、定期的に容量監視処理を実施する。第三の実施例に係る容量監視処理は、図６に示したステップ６０１およびステップ６０２を含む。第三の実施例に係る容量監視処理では、ステップ６０２により得られた容量情報を、ストレージサービス１２２１は、ストレージサービス別マネージャ１２０１に通知する。

第三の実施例では、ストレージサービス別マネージャ１２０１が、記憶デバイス１０１の物理容量を監視するノード１２１１と、定義された配分（格納割合）通りにデータをリバランスする（論理容量を制御する）リバランス機能とを連携するようになっている。ストレージサービス別マネージャ１２０１は、全てのノード１２１１から物理容量を表す情報を取得し、全てのノード１２１１の物理容量が平準化するように、リバランス機能が実施するリバランス（データ量の配分）を制御する。これにより、いずれのリバランス機能がそのリバランス機能に定義されている配分（格納割合）通りにデータをリバランスしても、物理容量の平準化を維持すること（言い換えれば、物理残容量の不足を避けること）が期待できる。

第四の実施例を説明する。その際、第一〜第三の実施例のうちの少なくとも１つとの相違点を主に説明し、第一〜第三の実施例のうちの少なくとも１つとの共通点については説明を省略又は簡略する。

第四の実施例は、マネージャが構成に含まれない点、アプリがアプリ別マネージャを有さない点、ストレージサービスがストレージサービス別マネージャを有さない点、および、計算機が計算機別マネージャを有する点が、第一〜第三の実施例と異なる。

図１３は、第四の実施例に係る計算機１３０２の構成を示す。

計算機１３０２のメモリ２５２には、アプリ２１２とノード１１１の他に計算機別マネージャ１３０１が格納される。計算機別マネージャ１３０１は、代表計算機１３０２のみが有してもよいし、各計算機１３０２が有し計算機１３０２間で協調して動作してもよい。本実施例では、代表計算機１３０２が計算機別マネージャ１３０１を有するものとする。

第四の実施例に係るテーブル設定処理、容量情報更新処理、および、リバランス制御処理は、第一の実施例に係る処理と同様である。ただし、これらの処理はマネージャ１０３ではなく、計算機別マネージャ１３０１によって実施される。

ストレージサービス２２１は、定期的に容量監視処理を実施する。第四の実施例に係る容量監視処理は、図６に示したステップ６０１およびステップ６０２を含む。第四の実施例に係る容量監視処理では、ステップ６０２の実施により得られた容量情報を、ストレージサービス２２１は、計算機別マネージャ１３０１に通知する。

第四の実施例では、計算機別マネージャ１３０１が、記憶デバイス１０１の物理容量を監視するノード１１１と、定義された配分（格納割合）通りにデータをリバランスする（論理容量を制御する）リバランス機能とを連携するようになっている。計算機別マネージャ１３０１は、全てのノード１１１から物理容量を表す情報を取得し、全てのノード１２１１の物理容量が平準化するように、リバランス機能が実施するリバランス（データ量の配分）を制御する。これにより、いずれのリバランス機能がそのリバランス機能に定義されている配分（格納割合）通りにデータをリバランスしても、物理容量の平準化を維持すること（言い換えれば、物理残容量の不足を避けること）が期待できる。

第五の実施例を説明する。その際、第一〜第四の実施例のうちの少なくとも１つとの相違点を主に説明し、第一〜第四の実施例のうちの少なくとも１つとの共通点については説明を省略又は簡略する。

図１４は、第五の実施例に係る情報システムの全体構成を示す。

少なくとも１つの計算機１４０２（例えば計算機Ａ）が、複数のＶＭ（Virtual Machine）１４０１を実行する。複数のＶＭは、ストレージＶＭ１４０１Ｓと、ゲストＶＭ１４０１Ｇとを含む。ストレージＶＭ１４０１Ｓは、仮想的なストレージ装置でよく、ゲストＶＭ１４０１Ｇは、仮想的なホスト計算機でよい。

ゲストＶＭ１４０１Ｇは、ストレージＶＭ１４０１ＳにＩ／Ｏ要求を発行するアプリ１４１２を実行する。

ストレージＶＭ１４０１は、複数の記憶デバイス１０１（例えば記憶デバイスＡおよびＢ）にそれぞれ対応した複数のノード１４１１（例えばノードｎ３１およびｎ３２）を実行する。例えば、代表ノード１４１１（例えばノードｎ３１）が、ストレージサービス２２１を有する。

第五の実施例でも、実施例１と同様の効果を奏することが期待できる。

以上、幾つかの実施例を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

例えば、ノード１１１と記憶デバイス１０１は、１：Ｎ（Ｎは１以上の整数）でもよい。

また、リバランス機能を有するエンティティの一例は、アプリに代えて又は加えて、ストレージサービスでもよい。ストレージサービスのリバランス機能は、複数の記憶デバイスに対応しストレージサービスが認識する複数の論理容量の配分を決められた配分となるようデータをリバランスする機能でよい。

１０２…計算機

Claims (15)

1. １以上のメモリを含んだ記憶部と、
   前記記憶部に接続され１以上のプロセッサを含んだプロセッサ部と
   を有し、
   前記プロセッサ部は、
   （Ａ）計算機システムに含まれる１以上の計算機に接続され圧縮機能を有する記憶デバイスを少なくとも１つ含んだ複数の記憶デバイスに対応した複数の物理容量を示す情報を含んだ容量情報を、前記記憶部に格納し、
   （Ｂ）前記容量情報に基づいて、リバランス機能を有するエンティティに対する指示内容を決定し、
   前記エンティティの前記リバランス機能は、前記複数の記憶デバイスに対応し前記エンティティが認識する複数の論理容量の配分を決められた配分となるようデータをリバランスする機能であり、
   前記指示内容は、論理容量配分に関する定義を含み、
   （Ｃ）前記決定した指示内容に従いデータをリバランスすることの指示であるリバランス指示を前記エンティティに送信する、
   データリバランス制御システム。
2. 前記計算機システムに含まれる前記１以上の計算機の少なくとも１つが、前記複数の記憶デバイスに対応した複数の物理容量を監視する機能とその複数の物理容量を表す情報を含んだ容量情報を通知する機能とを含んだストレージ制御機能を実行し、
   前記プロセッサ部は、リバランス制御機能を実行し、
   前記リバランス制御機能は、
   前記ストレージ制御機能から通知された容量情報を受信し、
   前記受信した容量情報を（Ａ）で格納し、
   （Ｂ）及び（Ｃ）を実行する、
   請求項１記載のデータリバランス制御システム。
3. 前記リバランス制御機能は、
   前記複数の記憶デバイスのうちの少なくとも１つについてリバランス実行要の条件を満たすか否かを判断し、
   前記判断の結果が真の場合に、（Ｂ）及び（Ｃ）を実行する、
   請求項２記載のデータリバランス制御システム。
4. 前記条件は、前記複数の記憶デバイスのうちの２以上の記憶デバイスの各々によって異なっており、
   （Ｂ）についてのエンティティは、前記判断の結果が真となった条件に関連付けられている記憶デバイスにデータを格納する１以上のエンティティのうちの少なくとも１つのエンティティである、
   請求項３記載のデータリバランス制御システム。
5. 前記少なくとも１つのエンティティが複数のリバランス機能を有している場合、（Ｂ）で決定される指示内容は、前記複数のリバランス機能のうちの優先度が最も高いリバランス機能に対する指示内容である、
   請求項４記載のデータリバランス制御システム。
6. 前記計算機システムを管理する管理システムを有し、
   前記管理システムは、前記記憶部、および、前記リバランス制御機能を実行する前記プロセッサ部を有する、
   請求項２記載のデータリバランス制御システム。
7. 前記計算機システムに含まれる前記１以上の計算機のうちの少なくとも１つの計算機を有し、
   前記少なくとも１つの計算機は、前記記憶部、および、前記リバランス制御機能及び前記ストレージ制御機能を実行する前記プロセッサ部を有する、
   請求項２記載のデータリバランス制御システム。
8. 前記プロセッサ部が、更に、前記エンティティを実行し、
   前記エンティティは、アプリケーションプログラムであり、前記リバランス制御機能を含む、
   請求項７記載のデータリバランス制御システム。
9. 前記リバランス制御機能は、そのリバランス制御機能を含むアプリケーションプログラムについてリバランス要否を制御する、
   請求項８記載のデータリバランス制御システム。
10. 前記ストレージ制御機能が、前記リバランス制御機能を含む、
    請求項７記載のデータリバランス制御システム。
11. 前記複数の記憶デバイスの各々について、
    前記物理容量は、その記憶デバイスに実際に格納されているデータの総量である物理使用容量と、その記憶デバイスの物理記憶容量とその記憶デバイスの物理使用容量との差分である物理残容量と、物理記憶容量に対する物理使用容量の割合である物理使用割合と、物理記憶容量に対する物理残容量の割合である物理残割合とのうちのいずれかであり、
    前記論理容量は、その記憶デバイスに基づく論理記憶空間に格納されているデータの総量である論理使用容量と、その記憶デバイスの論理記憶容量とその記憶デバイスの論理使用容量との差分である論理残容量と、論理記憶容量に対する論理使用容量の割合である論理使用割合と、論理記憶容量に対する論理残容量の割合である論理残割合とのうちのいずれかである、
    請求項１記載のデータリバランス制御システム。
12. 前記複数の物理容量の各々は、物理残容量である、
    請求項１記載のデータリバランス制御システム。
13. 前記複数の記憶デバイスの各々が、圧縮機能を有する、
    請求項１記載のデータリバランス制御システム。
14. 前記指示内容が含む前記定義は、前記複数の記憶デバイスのうちの少なくとも１つの記憶デバイスの物理残容量が枯渇することを避けるための論理容量配分に関する定義である、
    請求項１記載のデータリバランス制御システム。
15. 計算機システムに含まれる１以上の計算機に接続され圧縮機能を有する記憶デバイスを少なくとも１つ含んだ複数の記憶デバイスに対応した複数の物理容量を示す情報を含んだ容量情報に基づいて、リバランス機能を有するエンティティに対する指示内容を決定し、
    前記エンティティの前記リバランス機能は、前記複数の記憶デバイスに対応し前記エンティティが認識する複数の論理容量の配分を決められた配分となるようデータをリバランスする機能であり、
    前記指示内容は、論理容量配分に関する定義を含み、
    前記決定した指示内容に従いデータをリバランスすることの指示であるリバランス指示を前記エンティティに送信する、
    データリバランス制御方法。