JP7337869B2 - 分散ストレージシステム、及び管理方法 - Google Patents

Description

本発明は、複数のサーバにより構成される分散ストレージシステムにおいて、複数のサーバ間のデータのリバランス技術に関する。

ＡＩ（Artificial Intelligence）／ビッグデータ解析のための大容量データの格納先として、安価に容量・性能を拡張できるスケールアウト型の分散ストレージシステムが普及している。

多数のユーザやサービスのバックエンドとして使用されるデータレイク向けストレージでは、性能や容量不足時のスケールアウトや、省エネのためにリソース余剰時のスケールインが求められる。

一方、ストレージに格納するデータの増加にともない、ノード（サーバ）あたりの格納データ容量も増え、サーバ増設や減設時のデータリバランス時間が長期化し、クライアントからのアクセス性能への影響が問題となっている。

例えば、特許文献１には、多数のサーバから構成される分散ストレージにて、データ格納位置をデータのハッシュ値から動的に計算することで、データアクセス時のメタデータサーバアクセスを不要とする技術が開示されている。特許文献１の技術によると、メタデータサーバの性能ボトルネックがなくなるため、サーバ台数に比例した性能スケーラビリティを実現できる。

米国特許出願公開第２０１６／０３４９９９３号明細書

特許文献１に開示された技術にように、データのハッシュ値を用いてデータを分散配置する分散ファイルシステムでは、データの識別子からハッシュ関数を用いてハッシュ値を計算し、サーバ間でデータ量が均等となるようにデータ格納位置を決定する。ここで、ハッシュ関数とは、１つ以上の入力に対して、ランダムな値をハッシュ値として出力する関数のことを示す。そのため、サーバの増減設などによりサーバ構成が変わった場合、各サーバに格納するデータのハッシュ値の範囲も変わることとなり、サーバ間のデータのリバランスが必要となる。

このように、サーバ増減設によって各サーバに格納するデータのハッシュ値の範囲が変わった場合、多量のデータ移行が発生する。移行対象となるデータ量はハッシュ計算方式に依存するが、最低でもサーバ１台分以上のデータがサーバ間の移行対象となる。近年のデバイス大容量化により、サーバ１台あたりのデータ容量が大容量化しており、データ移行には、数日から数週間が必要となりうる。

また、サーバ間のデータ移行では、ネットワークを経由したサーバ間のデータ転送が必要となる。分散ファイルシステムでは、ネットワークリソースをクライアントからのデータアクセス処理と、リバランス処理とで共用するため、クライアントのアクセス性能への影響が問題となる。

本発明は、上記事情に鑑みなされたものであり、その目的は、分散ストレージシステムにおける複数のサーバ間のデータのリバランスを効率よく行うことのできる技術を提供することにある。

上記目的を達成するため、一観点に係る分散ストレージシステムは、複数の分散サーバと、複数の分散サーバによってアクセス可能な共有領域と、管理装置と、を備える分散ストレージシステムであって、前記共有領域は、複数の論理単位領域で構成され、それぞれの論理単位領域を管理する分散サーバが決められており、データ単位についてのハッシュ値に基づいて前記データ単位を格納する論理単位領域が決定され、決定された論理単位領域を管理する分散サーバが前記共有領域の前記データ単位に対するＩ／Ｏ処理を行うようになっており、前記管理装置のプロセッサは、前記論理単位領域を管理する分散サーバを変更する際に、変更後の論理単位領域と前記論理単位領域を管理する分散サーバとの対応関係を前記分散サーバに反映させる。

本発明によれば、分散ストレージシステムにおける複数のサーバ間のデータのリバランスを効率よく行うことができる。

図１は、第１実施形態に係る分散ストレージシステムの処理の概要を示す図である。 図２は、第１実施形態に係る分散ストレージシステムの構成図である。 図３は、第１実施形態に係る分散ＦＳサーバの構成図である。 図４は、第１実施形態に係る分散ボリューム構成管理テーブルの構成図である。 図５は、第１実施形態に係るサーバ統計情報テーブルの構成図である。 図６は、第１実施形態に係るストレージアレイの構成図である。 図７は、第１実施形態に係るＬＵ制御テーブルの構成図である。 図８は、第１実施形態に係るＬＵ統計情報テーブルの構成図である。 図９は、第１実施形態に係る管理サーバの構成図である。 図１０は、第１実施形態に係る分散ボリューム管理テーブルの構成図である。 図１１は、第１実施形態に係るサーバ管理テーブルの構成図である。 図１２は、第１実施形態に係るアレイ管理テーブルの構成図である。 図１３は、第１実施形態に係るＬＵ割当管理テーブルの構成図である。 図１４は、第１実施形態に係るクライアントサーバの構成図である。 図１５は、第１実施形態に係るハッシュ管理テーブルの構成図である。 図１６は、第１実施形態に係る分散ストレージシステムにおけるデータ格納処理の概要を示す図である。 図１７は、第１実施形態に係るボリューム作成処理のフローチャートである。 図１８は、第１実施形態に係るリバランス処理のフローチャートである。 図１９は、第１実施形態に係るＬＵ再割り当てプラン作成処理のフローチャートである。 図２０は、第１実施形態に係る分散ボリューム構成変更画面の一例である。 図２１は、第２実施形態に係る分散ストレージシステムの処理の概要を示す図である。 図２２は、第２実施形態に係るオブジェクトストレージサーバの構成図である。 図２３は、第２実施形態に係るクライアントサーバの構成図である。 図２４は、第２実施形態に係るストレージデバイスＩＤ管理テーブルの構成図である。 図２５は、第２実施形態に係る分散ストレージシステムにおけるデータ格納処理の概要を示す図である。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。

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

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

また、以下の説明では、記憶装置は、物理的な不揮発性の記憶デバイス（例えば補助記憶デバイス）、例えばＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）、ＳＣＭ（Ｓｔｏｒａｇｅ Ｃｌａｓｓ Ｍｅｍｏｒｙ）であってもよい。

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

また、以下の説明では、「プログラム」を動作の主体として処理を説明する場合があるが、プログラムは、プロセッサ（例えば、ＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜に記憶部（例えばメモリ）及び／又はインターフェース（例えばポート）を用いながら行うため、処理の動作の主体がプログラムとされてもよい。プログラムを動作の主体として説明された処理は、プロセッサ或いはそのプロセッサを有する計算機（例えば、サーバ）が行う処理としてもよい。また、コントローラ（ストレージコントローラ）は、プロセッサそれ自体であってもよいし、コントローラが行う処理の一部又は全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ又はコンピュータ読取可能な（例えば非一時的な）記憶メディアであってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、以下の説明では、要素の識別情報として、ＩＤが使用されるが、それに代えて又は加えて他種の識別情報が使用されてもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号における共通番号を使用し、同種の要素を区別して説明する場合は、その要素の参照符号を使用することがある。

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

＜第１実施形態＞
まず、第１実施形態に係る分散ストレージシステム０の概要について説明する。

図１は、第１実施形態に係る分散ストレージシステムの処理の概要を示す図である。図１は、分散ストレージシステム０におけるサーバ増設時のリバランス処理の概要を示す。

分散ストレージシステム０は、複数の分散ファイルシステム（ＦＳ）サーバ２（２Ａ，２Ｂ，２Ｃ，２Ｄ等）と、一台以上のストレージアレイ６と、を備える。分散ストレージシステム０は、ユーザデータを格納するための分散ボリューム１００（共有領域の一例）をクライアントサーバ１に対して提供する。ストレージアレイ６は、分散ＦＳサーバ２に対してユーザデータ用のＬＵ２００（論理単位領域の一例）を提供する。分散ボリューム１００は、複数の分散ＦＳサーバ２に提供されている複数のＬＵ２００をたばねて構成されている。図１の例では、分散ボリューム１００は、分散ＦＳサーバ１０Ａ（分散ＦＳサーバＡ）を含む一台以上の分散ＦＳサーバ２に提供されているＬＵ２００から構成される。本実施形態では、ストレージアレイ６は、ＬＵ２００を、ストレージアレイ６内でＲＡＩＤ（Redundant Array of Inexpensive Disks）構成を組むことでデータを冗長化しており、分散ＦＳサーバ２間でのデータの冗長化を行っていない。なお、分散ＦＳサーバ２にＲＡＩＤ制御を行う機能を備えるようにし、分散ＦＳサーバ側でＬＵ２００を冗長化するようにしてもよい。

分散ストレージシステム０は、分散ボリューム１００に格納するユーザデータを、例えば、ファイル単位で格納する。分散ストレージシステム０は、ファイル識別子からハッシュ値を計算し、ハッシュ値に従ってファイルを、分散ＦＳサーバ２間で均等化するように分散（均等分散という）する。ここで、ファイルとは、論理的なデータの管理単位（データ単位の一例）を示し、ファイルパスにより参照可能なデータのまとまりのことを示す。また、ファイルパスとは、ファイルの格納位置を示し、例えば、ファイルとファイルをグループ化したディレクトリとにより構成される木構造のノードを表す文字列である。分散ストレージシステム０においては、ＬＵ２００ごとに、均等に分割されたハッシュ値の範囲が割り当てられている。なお、分散ボリューム１００への格納単位は、ファイル単位に限られず、例えば、ファイルを分割したチャンクを単位としてもよい。この場合には、チャックごとのハッシュ値を計算し、チャンクを分散ＦＳサーバ２間で均等化するように分散させればよい。チャンクについては、例えば、チャンクが含まれるファイル識別子と、チャンクの識別子とに基づいてハッシュ値を算出するようにしてもよい。

分散ＦＳサーバ２は、ユーザデータを、ストレージアレイ６内に作成された細粒度のＬＵ２００に格納する。管理サーバ５は、リバランス時にＬＵ２００を割り当てる分散ＦＳサーバ２を変更する。この際、管理サーバ５は、分散ボリューム１００を構成するＬＵ２００の構成情報（ＬＵ割当管理テーブルＴ７（図１３参照））において、ＬＵ２００を担当するサーバ（担当サーバ）を変更することで、リバランス前後の各ＬＵ２００のハッシュ値の範囲が変わらないようにする。この結果、ネットワーク経由のデータ移行は不要となり、高速データリバランスを実現できる。

図１は、分散ＦＳサーバ２Ａ～２Ｄにより構成されている分散ストレージシステム０に対して、分散ＦＳサーバ２Ｅ（分散ＦＳサーバＥ）を増設した場合において、分散ＦＳサーバ２Ａ～２Ｄが管理しているＬＵ２００（ＬＵ１～ＬＵ２０）によって構成する分散ボリューム１００のデータをリバランスするリバランス処理の概要を示している。

分散ストレージシステム０は、分散ＦＳサーバ２Ｅが増設された場合、分散ＦＳサーバ２Ａ～２Ｄに割り当てられたＬＵ２００（ＬＵ１～ＬＵ２０）の一部のＬＵ２００（ＬＵ５，ＬＵ１０，ＬＵ１５，ＬＵ２０）を、分散ＦＳサーバ２Ｅに再割り当てする。この際、分散ボリューム１００におけるＬＵの構成を変更せず、各ＬＵ２００のハッシュ値の範囲が変わらないようにする。分散ストレージシステム０は、分散ＦＳサーバ２Ｅに再割り当て後、分散ＦＳ制御プログラムＰ１は、クライアントサーバ１に再割り当て後のデータ配置を通知し、クライアントサーバ１からのデータアクセスをリバランス後のデータ配置に対応する分散ＦＳサーバ２に切り替える。このようにすることで、分散ストレージシステム０は、分散ＦＳサーバ２間のデータ移行についてのネットワーク転送を伴うことなく、増設した分散ＦＳサーバ２Ｅへのデータリバランスを実現することができる。

以上説明したように、第１実施形態に係る分散ストレージシステム０では、分散ボリューム１００を、ストレージアレイ６内における多数（例えば、分散ＦＳサーバ２の数より多い数）のＬＵ２００で作成しておき、分散ＦＳサーバ２の構成が変わった際に、ＬＵ２００を分散ＦＳサーバ２間で再割り当てすることで、ネットワーク経由のデータ移行処理を不要とする。この結果、データリバランスの処理に要する時間を大幅に減らすことができる。

図２は、第１実施形態に係る分散ストレージシステムの構成図である。

分散ストレージシステム０は、１つ以上のクライアントサーバ１、管理装置の一例としての管理サーバ５、複数の分散サーバの一例としての分散ＦＳサーバ２、１つ以上のストレージアレイ６、フロントエンド（ＦＥ）ネットワーク７、バックエンド（ＢＥ）ネットワーク８、及びＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）９を備える。

クライアントサーバ１は、分散ＦＳサーバ２のクライアントである。クライアントサーバ１は、ネットワークＩ／Ｆ１３を介してＦＥネットワーク７に接続され、分散ＦＳサーバ２に対してユーザデータのファイルに対するＩ／Ｏ（ファイルＩ／Ｏ）を発行する。クライアントサーバ１は、ＮＦＳ（Network File System）、ＳＭＢ（Server Message Block）、ＡＦＰ（Apple Filing Protocol）などのプロトコルに従って、ファイルＩ／Ｏを行う。また、クライアントサーバ１は、様々な目的のために他の装置と通信することができる。

管理サーバ５は、分散ストレージシステム０の管理者が、分散ＦＳサーバ２及びストレージアレイ６を管理するためのサーバである。管理サーバ５は、管理ネットワークＩ／Ｆ５４を介してＦＥネットワーク７に接続され、分散ＦＳサーバ２とストレージアレイ６とに対して管理要求を発行する。管理サーバ５は、管理要求の通信形態として、ＳＳＨ（Secure Shell）を介したコマンド実行や、ＲＥＳＴ ＡＰＩ（Representational State Transfer Application Program Interface）などを使用する。管理サーバ５は、管理者に対し、ＣＬＩ（Command Line Interface）、ＧＵＩ（Graphical User Interface）、ＲＥＳＴ ＡＰＩなどの管理インターフェースを提供する。

分散ＦＳサーバ２は、クライアントサーバ１に対して論理的な記憶領域である分散ボリューム１００を提供する分散ファイルシステムを構成する。分散ＦＳサーバ２は、ＦＥネットワークＩ／Ｆ（図２では、ＦＥ Ｉ／Ｆと省略記載）２４を介してＦＥネットワーク７に接続され、クライアントサーバ１からのファイルＩ／Ｏと、管理サーバ５からの管理要求を受信し、処理する。分散ＦＳサーバ２は、ＨＢＡ２６を介してＳＡＮ９に接続され、ストレージアレイ６にユーザデータと制御情報を格納する。分散ＦＳサーバ２は、ＢＥネットワークＩ／Ｆ（図２では、ＢＥ Ｉ／Ｆと省略記載）２５を介してＢＥネットワーク８に接続され、他の分散ＦＳサーバ２との間で通信する。分散ＦＳサーバ２は、ＢＥネットワーク８を介して、他の分散ＦＳサーバ２とメタデータを交換したり、他の情報を交換したりする。分散ＦＳサーバ２は、ＢＭＣ（Baseboard Management Controller）２７を有し、常時（障害発生時も含む）、外部（例えば、管理サーバ５、分散ＦＳサーバ２）からの電源操作を受け付け、受け付けた電源操作を処理する。ＢＭＣ２７は、通信プロトコルとしてＩＰＭＩ（Intelligent Platform Management Interface）を使用できる。

ＳＡＮ９は、通信プロトコルとして、ＳＣＳＩ（Small Computer System Interface）、iSCSI、Non-Volatile Memory Express(ＮＶＭe)などを使用することが使用でき、また通信媒体としてＦＣ（ファイバチャネル）やＥｔｈｅｒｎｅｔ（登録商標）を使用できる。

ストレージアレイ６は、複数の記憶装置を備えている。ストレージアレイ６は、ＳＡＮ９に接続され、分散ＦＳサーバ２が管理するユーザデータおよび制御情報を格納するための論理的な記憶領域としてＬＵ２００を分散ＦＳサーバ２に提供する。

図２に示す分散ストレージシステム０においては、ＦＥネットワーク７、ＢＥネットワーク８、及びＳＡＮ９を分離したネットワークとしているが、この構成に限られず、ＦＥネットワーク７、ＢＥネットワーク８、及びＳＡＮ９の少なくとも２つを同一のネットワークとして構成してもよい。

また、図２に示す分散ストレージシステム０においては、クライアントサーバ１と、管理サーバ５と、分散ＦＳサーバ２とを物理的に別のサーバとした例を示しているが、この構成に限られず、例えば、クライアントサーバ１と分散ＦＳサーバ２とを同じサーバで構成してもよく、管理サーバ５と分散ＦＳサーバ２とを同じサーバで構成してもよい。

次に、分散ＦＳサーバ２の構成について説明する。

図３は、第１実施形態に係る分散ＦＳサーバの構成図である。

分散ＦＳサーバ２は、ＣＰＵ２１、メモリ２２、記憶装置２３、ＦＥネットワークＩ／Ｆ２４、ＢＥネットワークＩ／Ｆ２５、ＨＢＡ２６、及びＢＭＣ２７を有する。

ＣＰＵ２１は、メモリ２２上のプログラムに従って処理することによって、所定の機能を提供する。

メモリ２２は、例えば、ＲＡＭ（ＲＡＮＤＯＭ ＡＣＣＥＳＳ ＭＥＭＯＲＹ）であり、ＣＰＵ２１で実行されるプログラムや、必要な情報を記憶する。メモリ２２は、分散ＦＳ制御プログラムＰ１、プロトコル処理プログラムＰ３、ストレージ接続プログラムＰ５、統計情報採取プログラムＰ７、分散ボリューム構成管理テーブルＴ０、及びサーバ統計情報テーブルＴ１を記憶する。

分散ＦＳ制御プログラムＰ１は、ＣＰＵ２１に実行されることにより、他の分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１と協調し、分散ファイルシステム（分散ＦＳ）を構成する。分散ＦＳ制御プログラムＰ１は、ＣＰＵ２１に実行されることにより、クライアントサーバ１に対して分散ボリューム１００を提供する。分散ＦＳ制御プログラムＰ１は、クライアントサーバ１が分散ボリューム１００に格納するファイルを、ストレージアレイ６内のＬＵ２００に格納する処理を行う。

プロトコル処理プログラムＰ３は、ＣＰＵ２１に実行されることにより、ＮＦＳ、ＳＭＢなどのネットワーク通信プロトコルに従う要求を受信し、分散ＦＳへのファイルＩ／Ｏへと変換し、分散ＦＳ制御プログラムＰ１に渡す。

ストレージ接続プログラムＰ５は、ＣＰＵ２１に実行されることにより、ストレージアレイ６のＬＵ２００に格納されたデータを読み取る。ストレージ接続プログラムＰ５は、ＣＰＵ２１に実行されることにより、分散ＦＳ制御プログラムＰ１（分散ＦＳサーバ２）に割り当てられたＬＵ２００に対して、ストレージアクセス用のプロトコルを介してストレージアレイ６と通信する制御を行う。

統計情報採取プログラムＰ７は、ＣＰＵ２１に実行されることにより、分散ＦＳサーバ２の負荷を定期的に監視し、負荷の情報をサーバ統計情報テーブルＴ１に格納する処理を行う。

分散ボリューム構成管理テーブルＴ０は、分散ボリューム１００の構成を管理するためのテーブルである。分散ボリューム構成管理テーブルＴ０の詳細については、図４を用いて後述する。

サーバ統計情報テーブルＴ１は、分散ＦＳサーバ２の負荷の情報を格納する。サーバ統計情報テーブルＴ１の詳細については、図５を用いて後述する。

ＦＥネットワークＩ／Ｆ２４は、ＦＥネットワーク７に接続するための通信インターフェースデバイスである。ＢＥネットワークＩ／Ｆ２５は、ＢＥネットワーク８に接続するための通信インターフェースデバイスである。ＨＢＡ２６は、ＳＡＮ９に接続するための通信インターフェースデバイスである。

ＢＭＣ２７は、分散ＦＳサーバ２の電源制御インターフェースを提供するデバイスである。ＢＭＣ２７は、ＣＰＵ２１及びメモリ２２と独立して動作し、ＣＰＵ２１又はメモリ２２に障害が発生した場合でも、外部からの電源制御要求を受け付けて電源制御を処理することができる。

記憶装置２３は、分散ＦＳサーバ２で使用する各種プログラムを格納した不揮発性記憶媒体である。記憶装置２３は、ＨＤＤ、ＳＳＤ、ＳＣＭであってもよい。

次に、分散ボリューム構成管理テーブルＴ０の構成について詳細に説明する。

図４は、第１実施形態に係る分散ボリューム構成管理テーブルの構成図である。

分散ボリューム構成管理テーブルＴ０は、分散ボリューム１００を構成するための構成情報を格納する。分散ボリューム構成管理テーブルＴ０は、分散ＦＳ制御プログラムＰ１によって利用される。分散ＦＳ制御プログラムＰ１は、他の分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１と協働することにより、全ての分散ＦＳサーバ２の分散ボリューム構成管理テーブルＴ０が同期して、常に同一内容となるように同期処理を行う。

分散ボリューム構成管理テーブルＴ０は、分散ボリューム１００毎のエントリを格納する。分散ボリューム構成管理テーブルＴ０のエントリは、分散ＶｏｌＩＤ Ｃ１と、対応する分散ボリューム１００の各ＬＵに対応するサーバＩＤ Ｃ２及びマウントポイントＣ３とのフィールドを含む。

分散ボリュームＩＤ Ｃ１には、エントリに対応する分散ボリューム１００の識別子（分散ボリュームＩＤ）が格納される。サーバＩＤ Ｃ２には、エントリに対応する分散ボリューム１００のＬＵ２００を構成する分散ＦＳサーバ２の識別子（サーバＩＤ）が格納される。マウントポイントＣ３には、エントリに対応する分散ボリューム１００を構成するＬＵ２００をマウントした分散ＦＳサーバ２におけるマウントポイントが格納される。ここで、マウントポイントとは、マウントしたＬＵ２００に対してアクセスする際の仮想的なディレクトリのことをいう。この分散ボリューム管理テーブルＴ０によると、分散ボリュームを構成する各ＬＵの管理する分散ＦＳサーバ２及びマウントポイントを特定することができる。

次に、サーバ統計情報テーブルＴ１の構成について詳細に説明する。

図５は、第１実施形態に係るサーバ統計情報テーブルの構成図である。

サーバ統計情報テーブルＴ１は、分散ＦＳサーバ２のハードウェアの負荷に関する統計情報を格納する。サーバ統計情報テーブルＴ１には、統計情報採取プログラムＰ７により、監視された分散ＦＳファイル２のハードウェアの負荷の情報が格納される。

サーバ統計情報テーブルＴ１は、ＣＰＵ使用率Ｃ１０１と、ＮＷ使用量Ｃ１０２と、ＨＢＡ使用量Ｃ１０３とのフィールドを含む。

ＣＰＵ使用率Ｃ１０１には、このサーバ統計情報テーブルＴ１を格納する分散ＦＳサーバ２（自分散ＦＳサーバ）のＣＰＵ使用率が格納される。ＮＷ使用量Ｃ１０２には、自分散ＦＳサーバのネットワーク流量が格納される。ＨＢＡ使用量Ｃ１０３には、自分散ＦＳサーバのＨＢＡ使用量が格納される。

なお、本実施形態では、サーバ統計情報テーブルＴ１は、統計情報として、ＣＰＵ使用率、ネットワーク流量、ＨＢＡ使用量を格納するようにしているが、これに限られず、統計情報にネットワークパケット数や、ディスクアクセス回数、メモリ使用量等を含めるようにしてもよい。

次に、ストレージアレイ６の構成について説明する。

図６は、第１実施形態に係るストレージアレイの構成図である。

ストレージアレイ６は、ＣＰＵ６１、メモリ６２、ストレージＩ／Ｆ（ＳｔｏｒａｇｅＩ／Ｆ）６３、記憶装置６４、ＨＢＡ６５、及びＦＥネットワークＩ／Ｆ６６を有する。

ＣＰＵ６１は、メモリ６２上のプログラムに従って処理することによって、所定の機能を提供する。

メモリ６２は、例えば、ＲＡＭであり、ＣＰＵ６１で実行されるプログラムや、必要な情報を記憶する。メモリ６２は、ＩＯ制御プログラムＰ１１、アレイ管理プログラムＰ１３、ＬＵ制御テーブルＴ２、及びＬＵ統計情報テーブルＴ３を記憶する。

ＩＯ制御プログラムＰ１１は、ＣＰＵ６１に実行されることにより、ＨＢＡ６５経由で受信したＬＵ２００に対するＩ／Ｏ要求を処理し、記憶装置６４に対するデータの読み書きを行う。アレイ管理プログラムＰ１３は、ＣＰＵ６１に実行されることにより、管理サーバ５から受信したＬＵ管理要求に従い、ストレージアレイ６内のＬＵ２００の作成、拡張、縮小、削除を行う。

ＬＵ制御テーブルＴ２は、ＬＵ２００の制御情報を管理するためのテーブルである。ＬＵ制御テーブルＴ２の詳細については、図７を用いて後述する。

ＬＵ統計情報テーブルＴ３は、ＬＵ２００の負荷の情報を格納する。ＬＵ統計情報テーブルＴ３の詳細については、図８を用いて後述する。

ストレージＩ／Ｆ６３は、ＣＰＵ６１による記憶装置６４へのデータの読み書きを仲介するインターフェースであり、ＣＰＵ６１とストレージＩ／Ｆ６３との間の通信には、ＦＣ（ファイバチャネル）、ＳＡＴＡ（Serial Attached Technology Attachment）、ＳＡＳ（Serial Attached SCSI）、ＩＤＥ（Integrated Device Electronics）などのインターフェースが用いられる。

記憶装置６４は、ストレージアレイ６で使用する各種プログラムや、分散ＦＳサーバ２によるユーザデータや制御情報を記録する記憶媒体である。記憶装置６４の記憶媒体としては、ＨＤＤ、ＳＳＤ、ＳＣＭ、フラッシュメモリ、光ディスク、磁気テープなどのような多くの種類の記憶媒体を使用することができる。

ＦＥネットワークＩ／Ｆ６６は、ＦＥネットワーク７に接続するための通信インターフェースデバイスである。ＨＢＡ６５は、ＳＡＮ９に接続するための通信インターフェースデバイスである。

次に、ＬＵ制御テーブルＴ２の構成について詳細に説明する。

図７は、第１実施形態に係るＬＵ制御テーブルの構成図である。

ＬＵ制御テーブルＴ２は、ストレージアレイ６が提供するＬＵ２００の制御情報を格納する。ＬＵ制御テーブルＴ２は、ＬＵ２００毎のエントリを格納する。ＬＵ制御テーブルＴ２のエントリは、ＬＵＮ Ｃ２０１と、ＷＷＮ（World Wide Name）Ｃ２０２と、論理容量Ｃ２０３と、ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ２０４と、ＲＡＩＤ種別Ｃ２０５と、Ｄｉｓｋ ＩＤ Ｃ２０６と、Ｄｉｓｋ種別Ｃ２０７と、物理容量Ｃ２０８とのフィールドを含む。

ＬＵＮ Ｃ２０１には、エントリに対応するＬＵ２００のストレージアレイ６内での識別子（ＬＵＮ）が格納される。ＷＷＮ Ｃ２０２には、エントリに対応するＬＵのＬＵＮをＳＡＮ９で一意に識別するための識別子（ＷＷＮ）が格納される。ＷＷＮは、分散ＦＳサーバ２がＬＵ２００にアクセスする際に使用する。論理容量Ｃ２０３には、エントリに対応するＬＵ２００の論理的な容量（論理容量）が格納される。

ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ２０４には、エントリに対応するＬＵ２００を構成するＲＡＩＤグループの識別子が格納される。ここで、ＲＡＩＤグループとは、１台以上の記憶媒体（例えば、ディスク）から構成されるデータの読み書きが可能な論理的な記憶領域を示す。なお、１つのＲＡＩＤグループにより複数のＬＵ２００を構成してもよい。ＲＡＩＤ種別Ｃ２０５には、エントリに対応するＲＡＩＤグループＩＤのＲＡＩＤグループの種別（ＲＡＩＤ種別：ＲＡＩＤレベル）が格納される。ＲＡＩＤ種別としては、例えば、ＲＡＩＤ１（ｎＤ＋ｍＤ）やＲＡＩＤ５（ｎＤ＋１Ｐ）、ＲＡＩＤ６（ｎＤ＋２Ｐ）などがある。なお、ｎとｍは、それぞれでＲＡＩＤグループ内のデータ数に対する冗長データ数をあらわす。

Ｄｉｓｋ ＩＤ Ｃ２０６には、エントリに対応するＲＡＩＤグループを構成するディスクの識別子（Ｄｉｓｋ ＩＤ）が格納される。Ｄｉｓｋ ＩＤとしては、ディスクのシリアル番号などを用いてもよい。Ｄｉｓｋ種別Ｃ２０７には、エントリに対応するディスクの種別（Ｄｉｓｋ種別）が格納される。Ｄｉｓｋ種別としては、ＮＶＭｅ ＳＳＤ、ＳＳＤ、ＨＤＤなどがある。物理容量Ｃ２０８には、エントリに対応するディスクの物理的な記憶容量が格納される。

次に、ＬＵ統計情報テーブルＴ３の構成について詳細に説明する。

図８は、第１実施形態に係るＬＵ統計情報テーブルの構成図である。

ＬＵ統計情報テーブルＴ３は、ストレージアレイ６のＬＵ２００についての負荷情報を格納する。ＬＵ統計情報テーブルＴ３には、ＩＯ制御プログラムＰ１１により、監視されたストレージアレイ６の負荷が定期的に格納される。ＬＵ統計情報テーブルＴ３は、ＬＵ毎のエントリを格納する。ＬＵ統計情報テーブルＴ３のエントリは、ＬＵＮ Ｃ３０１と、リードＩＯＰＳ Ｃ３０２と、リード流量Ｃ３０３と、ライトＩＯＰＳ Ｃ３０４と、ライト流量Ｃ３０５とのフィールドを含む。

ＬＵＮ Ｃ３０１には、エントリに対応するＬＵのＬＵＮが格納される。リードＩＯＰＳ Ｃ３０２には、エントリに対応するＬＵにおけるリードのＩＯＰＳ（Input/Output Per Second）が格納される。リード流量Ｃ３０３には、エントリに対応するＬＵに対する単位時間当たりのリードのデータ量（リード流量）が格納される。ライトＩＯＰＳ Ｃ３０４には、エントリに対応するＬＵに対するライトのＩＯＰＳが格納される。ライト流量Ｃ３０５には、エントリに対応するＬＵに対する単位時間当たりのライトのデータ量（ライト流量）が格納される。

次に、管理サーバ５の構成について説明する。

図９は、第１実施形態に係る管理サーバの構成図である。

管理サーバ５は、プロセッサの一例としてのＣＰＵ５１、メモリ５２、記憶装置５３、及びＦＥネットワークＩ／Ｆ５４を有する。管理サーバ５には、ディスプレイ５５や入力装置５６が接続されている。

ＣＰＵ５１は、メモリ５２上のプログラムに従って処理することによって、所定の機能を提供する。

メモリ５２は、例えば、ＲＡＭであり、ＣＰＵ５１で実行されるプログラムや、必要な情報を記憶する。メモリ５２は、管理プログラムＰ２１、リバランス制御プログラムＰ２２、分散ボリューム管理テーブルＴ４、サーバ管理テーブルＴ５、アレイ管理テーブルＴ６、及びＬＵ割当管理テーブルＴ７を記憶する。なお、特許請求の範囲の管理プログラムは、管理プログラムＰ２１及びリバランス制御プログラムＰ２２に対応する。

管理プログラムＰ２１は、ＣＰＵ５１に実行されることにより、管理者から入力装置５６を介して受け付けた管理要求に従って、分散ＦＳサーバ２及びストレージアレイ６に対して構成変更要求を発行する。ここで、管理者からの管理要求は、分散ボリューム１００の作成・削除、分散ＦＳサーバ２の増設、減設などの要求を含む。また、構成変更要求は、ＬＵ作成・削除・拡張・縮小、ＬＵパスの追加、削除、変更の要求を含む。

リバランス制御プログラムＰ２２は、ＣＰＵ５１に実行されることにより、分散ＦＳサーバ２、ストレージアレイ６と協調して、データのリバランス処理を行う。

分散ボリューム管理テーブルＴ４は、分散ボリューム１００を管理するためのテーブルである。分散ボリューム管理テーブルＴ４の詳細については、図１０を用いて後述する。

サーバ管理テーブルＴ５は、分散ＦＳサーバ２を管理するためのテーブルである。サーバ管理テーブルＴ５の詳細については、図１１を用いて後述する。

アレイ管理テーブルＴ６は、ストレージアレイ６を管理するためのテーブルである。アレイ管理テーブルＴ６の詳細については、図１２を用いて後述する。

ＬＵ割当管理テーブルＴ７は、ＬＵ２００の割り当てを管理するためのテーブルである。ＬＵ割当管理テーブルＴ７の詳細については、図１３を用いて後述する。

ＦＥネットワークＩ／Ｆ５４は、ＦＥネットワーク７に接続するための通信インターフェースデバイスである。

記憶装置５３は、管理サーバ５で使用する各種プログラムを格納した不揮発性記憶媒体である。記憶装置５３は、ＨＤＤ、ＳＳＤ、ＳＣＭであってもよい。

入力装置５６は、キーボードやマウスやタッチパネル等であり、利用者（あるいは管理者）の操作を受け付ける。ディスプレイ５５は、各種情報を表示する装置であり、分散ストレージシステム０を管理するための管理インターフェースの画面（例えば、分散ボリューム構成変更画面、図２０参照）を表示する。

次に、分散ボリューム管理テーブルＴ４の構成について詳細に説明する。

図１０は、第１実施形態に係る分散ボリューム管理テーブルの構成図である。

分散ボリューム管理テーブルＴ４は、管理プログラムＰ２１が分散ボリューム１００を管理するための管理情報を格納する。分散ボリューム管理テーブルＴ４は、分散ボリューム１００毎のエントリを格納する。分散ボリューム管理テーブルＴ４のエントリは、分散Ｖｏｌ ＩＤ Ｃ４０１と、ＬＵ ＩＤ Ｃ４０２と、ＷＷＮ Ｃ４０３と、ストレージアレイＩＤ Ｃ４０４と、ＬＵＮ Ｃ４０５とのフィールドを含む。

分散Ｖｏｌ ＩＤ Ｃ４０１には、エントリに対応する分散ボリューム１００の識別子（分散ボリュームＩＤ）が格納される。ＬＵ ＩＤ Ｃ４０２には、エントリに対応する分散ボリューム１００を構成する１以上のＬＵ２００を分散ストレージシステム０で一意に識別する識別子（ＬＵ ＩＤ）が格納される。ＷＷＮ Ｃ４０３には、エントリに対応するＬＵ ＩＤのＬＵ２００のＷＷＮが格納される。ストレージアレイＩＤ Ｃ４０４には、エントリに対応するＬＵ２００を格納するストレージアレイ６の識別子（ストレージアレイＩＤ）が格納される。ＬＵＮ４０５には、エントリに対応するＬＵ２００のＬＵＮが格納される。

次に、サーバ管理テーブルＴ５の構成について詳細に説明する。

図１１は、第１実施形態に係るサーバ管理テーブルの構成図である。

サーバ管理テーブルＴ５は、管理プログラムＰ２１が分散ＦＳサーバ２を管理するための管理情報を格納する。サーバ管理テーブルＴ５は、分散ＦＳサーバ２毎のエントリを格納する。サーバ管理テーブルＴ５のエントリは、サーバＩＤ Ｃ５０１と、接続ストレージアレイＣ５０２と、ＩＰアドレスＣ５０３と、ＢＭＣアドレスＣ５０４と、ＭＴＴＦ Ｃ５０５と、起動時間Ｃ５０６とのフィールドを含む。

サーバＩＤ Ｃ５０１には、エントリに対応する分散ＦＳサーバ２を分散ストレージシステム０内で一意に識別可能な分散ＦＳサーバ２の識別子（サーバＩＤ）が格納される。接続ストレージアレイＣ５０２には、エントリに対応する分散ＦＳサーバ２からアクセス可能なストレージアレイ６の識別子（ストレージアレイＩＤ）が格納される。ＩＰアドレスＣ５０３には、エントリに対応する分散ＦＳサーバ２のＩＰアドレスが格納される。

ＢＭＣアドレスＣ５０４には、エントリに対応する分散ＦＳサーバ２のＢＭＣ２７のＩＰアドレスが格納される。ＭＴＴＦ Ｃ５０５には、エントリに対応する分散ＦＳサーバ２の平均故障時間（ＭＴＴＦ：Mean Time To Failure)が格納される。ＭＴＴＦとしては、エントリに対応する分散ＦＳサーバ又はサーバ種別についてのカタログ値を使用してもよい。起動時間Ｃ５０６には、エントリに対応する分散ＦＳサーバ２の正常状態における起動時間が格納される。この起動時間は、管理プログラムＰ２１がフェールオーバ時間を見積もるために使用される。

なお、図１１に示すサーバ管理テーブルＴ５においては、分散ＦＳサーバ２、ＢＭＣ２７へのアクセスのための情報としてＩＰアドレスを格納するようにしているが、これに代えてホスト名を格納するようにしてもよい。

次に、アレイ管理テーブルＴ６の構成について詳細に説明する。

図１２は、第１実施形態に係るアレイ管理テーブルの構成図である。

アレイ管理テーブルＴ６は、管理プログラムＰ２１がストレージアレイ６と通信するため、及びＬＵ２００の割り当てを決定するために使用するストレージアレイ６の構成情報を格納する。アレイ管理テーブルＴ６は、ストレージアレイ６毎のエントリを格納する。アレイ管理テーブルＴ６のエントリは、ストレージアレイＩＤ Ｃ６０１と、管理ＩＰアドレスＣ６０２と、ＬＵ ＩＤ Ｃ６０３とのフィールドを含む。

ストレージアレイＩＤ Ｃ６０１には、エントリに対応するアウトレージアレイ６を分散ストレージシステム０内で一意に識別可能な識別子（ストレージアレイＩＤ）が格納される。管理ＩＰアドレスＣ６０２には、エントリに対応するストレージアレイ６の管理用のＩＰアドレスが格納される。なお、ＩＰアドレスに代えて、ホスト名としてもよい。ＬＵ ＩＤ Ｃ６０３には、エントリに対応するストレージアレイ６が提供するＬＵ２００のＬＵ ＩＤが格納される。

次に、ＬＵ割当管理テーブルＴ７の構成について詳細に説明する。

図１３は、第１実施形態に係るＬＵ割当管理テーブルの構成図である。

ＬＵ割当管理テーブルＴ７は、管理プログラムＰ２１が分散ＦＳサーバ２に対して割り当てるＬＵ２００を管理するための管理情報を格納する。ＬＵ割当管理テーブルＴ７は、分散ボリューム１００のＬＵ２００毎のエントリを格納する。ＬＵ割当管理テーブルＴ７のエントリは、分散ボリュームＩＤ Ｃ７０１と、ＬＵ ＩＤ Ｃ７０２と、サーバＩＤ Ｃ７０３と、マウントポイントＣ７０４とのフィールドを含む。

分散ボリュームＩＤ Ｃ７０１には、エントリに対応する分散ボリューム１００の識別子（分散ボリュームＩＤ）が格納される。ＬＵ ＩＤ Ｃ７０２には、エントリに対応する分散ボリューム１００のＬＵ２００の識別子（ＬＵ ＩＤ）が格納される。サーバＩＤ Ｃ７０３には、エントリに対応するＬＵ２００が割当てられている分散ＦＳサーバ２のサーバＩＤが格納される。マウントポイントＣ７０４には、エントリに対応するＬＵ２００の分散ＦＳサーバ２でのマウントポイントが格納される。

次に、クライアントサーバ１の構成について説明する。

図１４は、第１実施形態に係るクライアントサーバの構成図である。

クライアントサーバ１は、ＣＰＵ１１、メモリ１２、記憶装置１４、及びＦＥネットワークＩ／Ｆ１３を有する。

ＣＰＵ１１は、メモリ１２上のプログラムに従って処理することによって、所定の機能を提供する。

メモリ１２は、例えば、ＲＡＭであり、ＣＰＵ１１で実行されるプログラムや、必要な情報を記憶する。メモリ１２は、アプリケーションプログラムＰ３１、分散ＦＳクライアントプログラムＰ３２、及びハッシュ管理テーブルＴ８を記憶する。

アプリケーションプログラムＰ３１は、ＣＰＵ１１に実行されることにより、分散ボリューム１００を利用してデータ処理を行う。アプリケーションプログラムＰ３１は、例えば、ＲＤＢＭＳ（Relational Database Management System）や、ＶＭ Ｈｙｐｅｒｖｉｓｏｒなどのプログラムであってもよい。

分散ＦＳクライアントプログラムＰ３２は、ＣＰＵ１１に実行されることにより、分散ＦＳサーバ２に対してファイルＩ／Ｏを発行して分散ボリューム１００に対するデータの読み書きを行う。分散ＦＳクライアントプログラムＰ３２は、ネットワーク通信プロトコルにおいて、クライアント側の制御を実行する。分散ＦＳクライアントプログラムＰ３２は、新規ディレクトリ作成時に該当ディレクトリと対応する物理ディレクトリを全ＬＵ２００に対して作成する。この際、分散ＦＳクライアントプログラムＰ３２は、ＬＵ２００内のディレクトリのメタデータに、そのＬＵ２００に割り当てるハッシュ値を記録する。分散ＦＳクライアントプログラムＰ３２は、ディレクトリにアクセスした際に、全ＬＵ２００の物理ディレクトリのメタデータを読み取り、ハッシュ管理テーブルＴ８に記録する。分散ＦＳクライアントプログラムＰ３２は、ファイルアクセス時にファイル識別子のハッシュ値を計算し、ハッシュ管理テーブルＴ８を参照し、ハッシュ値に基づいて格納先となるＬＵ２００を特定する。

ハッシュ管理テーブルＴ８は、ＬＵ２００に格納されるファイルのハッシュ情報を管理するためのテーブルである。ハッシュ管理テーブルＴ８の詳細については、図１５を用いて後述する。

ＦＥネットワークＩ／Ｆ１３は、ＦＥネットワーク７に接続するための通信インターフェースデバイスである。

記憶装置１４は、クライアントサーバ１で使用する各種プログラムを格納した不揮発性記憶媒体である。記憶装置１４は、ＨＤＤ、ＳＳＤ、ＳＣＭであってもよい。

次に、ハッシュ管理テーブルＴ８の構成について詳細に説明する。

図１５は、第１実施形態に係るハッシュ管理テーブルの構成図である。

ハッシュ管理テーブルＴ８は、クライアントサーバ１上の分散ＦＳクライアントプログラムＰ３２が分散ＦＳサーバ２で管理されているファイルにアクセスするためのハッシュ情報を格納する。ハッシュ管理テーブルＴ８は、ディレクトリパスＣ８０１と、サーバＩＤ Ｃ８０２と、ＬＵ ＩＤ Ｃ８０３と、ハッシュ範囲Ｃ８０４とのフィールドを含む。

ディレクトリパスＣ８０１には、ハッシュ値を持つディレクトリのパス（ディレクトリパス）が格納される。分散ボリューム１００内の全ディレクトリは、ＬＵ２００ごとにハッシュ値の範囲が対応付けられている。サーバＩＤ Ｃ８０２には、エントリに対応するディレクトリ以下のファイルを格納する分散ＦＳサーバ２の識別子（サーバＩＤ）が格納される。サーバＩＤ Ｃ８０２には、エントリに対応するディレクトリパスにおける全サーバのサーバＩＤが格納される。

ＬＵ ＩＤ Ｃ８０３には、エントリに対応するディレクトリパスの分散ＦＳサーバ２に管理されているＬＵ２００の識別子（ＬＵ ＩＤ）が格納される。ＬＵ ＩＤ Ｃ８０３には、エントリに対応する分散ＦＳサーバ２が管理する全ＬＵ２００のＬＵ ＩＤが格納される。ハッシュ範囲Ｃ８０４には、エントリに対応するＬＵ ＩＤのＬＵ２００に格納されるファイルについてのハッシュ値の範囲が格納される。

次に、第１実施形態に係る分散ストレージシステム０におけるデータ格納処理の概要を説明する。

図１６は、第１実施形態に係る分散ストレージシステムにおけるデータ格納処理の概要を示す図である。

図１６は、クライアントサーバ１が、分散ＦＳサーバ２Ａ～２Ｃにより構成された分散ボリューム１００にディレクトリＤ１Ａ～Ｄ１Ｃ（ＤｉｒＡ）と、ファイルＦ１～Ｆ３（ＦｉｌｅＡ～ＦｉｌｅＣ）を格納する場合の処理の概要を示している。

分散ボリューム１００内のディレクトリは、分散ボリューム１００を構成する全ての分散ＦＳサーバ２内のＬＵ２００に、同じディレクトリパスとして作成される。ここで、ディレクトリパスとは、ディレクトリにアクセスするための文字列のことを示す。分散ボリューム１００内の複数のファイルは、ファイル識別子のハッシュ値に基づいて分散ＦＳサーバ２間で分散して格納される。ここで、ファイル識別子として、ファイルパスやファイル生成時に割り当てた乱数を使用してもよい。この結果、ＤｉｒＡが分散ＦＳサーバ２の全てのＬＵ２００に存在し、ＦｉｌｅＡ～ＦｉｌｅＣがそれぞれ異なるＬＵ２００に存在するようになる。

各分散ＦＳサーバ２のＬＵ２００内のディレクトリＤ１（Ｄ１Ａ～Ｄ１Ｃ）には、メタデータとしてそのＬＵ２００に割り当てられたハッシュ値の範囲Ｈ１（Ｈ１Ａ～Ｈ１Ｃ）が管理される。

クライアントサーバ１上の分散ＦＳクライアントプログラムＰ３２は、新規ディレクトリ作成時に各ＬＵ２００のハッシュ値の範囲Ｈ１を決定し、各ＬＵ２００のディレクトリＤ１のメタデータに格納する。また、分散ＦＳクライアントプログラムＰ３２は、ディレクトリに対するアクセス時に全分散ＦＳサーバ２から、全ＬＵ２００分のハッシュ値の範囲Ｈ１（Ｈ１Ａ～Ｈ１Ｃ）を取得し、ハッシュ管理テーブルＴ８に記録する。

分散ＦＳクライアントプログラムＰ３２は、ファイルアクセス時に、ファイル識別子に基づいてハッシュ値を計算し、ハッシュ管理テーブルＴ８を参照し、計算したハッシュ値に対応するＬＵ２００を管理するサーバを特定する。

次に、第１実施形態に係る分散ストレージシステム０の処理動作について説明する。

図１７は、第１実施形態に係るボリューム作成処理のフローチャートである。

ボリューム作成処理は、管理サーバ５によって実行される処理であり、管理プログラムＰ２１（厳密には、管理プログラムＰ２１を実行する管理サーバ５のＣＰＵ５１）は、管理者から分散ボリュームの作成要求（分散ボリューム作成要求）を受け付けた際、例えば、入力装置５６から、又は管理者が使用する端末から受け付けた際に、分散ボリューム作成要求に基づいて、ストレージアレイ６に細粒度の共有のＬＵ２００を作成する処理である。

ステップＳ１１０：管理プログラムＰ２１は、管理者から新規ボリューム名、ボリュームサイズ、稼働率要件等を含んだ分散ボリューム作成要求を受け付ける。

ステップＳ１２０：管理プログラムＰ２１は，分散ボリュームに加えることのできる最大のサーバ数に基づいて、新規ボリュームを構成するＬＵ数（作成ＬＵ数）を決定する。

具体的には、例えば、管理プログラムＰ２１は、サーバ管理テーブルＴ５を参照し、分散ストレージシステム０を構成する分散ＦＳサーバ２のＭＴＴＦの平均値を算出し、分散ＦＳサーバの台数を変化させた場合における、それぞれの台数における稼働率見積りを式（１）に基づいて算出し、その結果に基づいて、分散ボリューム作成要求の稼働率要件を満たすような最大のサーバの台数（最大サーバ数）を計算する。管理プログラムＰ２１は、最大サーバ数と同数を、分散ボリュームを構成する細粒度のＬＵ２００の個数に決定する。なお、ＬＵ２００の個数は、分散ストレージシステム０の現在の分散ＦＳサーバの台数よりも大きく最大サーバ数以下の数としてもよい。

稼働率見積り＝Π（（ＭＴＴＦ_{ｓｅｒｖｅｒ}－Ｆ．ｏ．Ｔｉｍｅ_{ｓｅｒｖｅｒ}）／（ＭＴＴＦ_{ｓｅｒｖｅｒ}）） ・・・（１）

ここで、Πは、総乗を示す関数であり、本実施形態では、対象とするサーバの台数分の総乗をすることを表し、ＭＴＴＦ_{ｓｅｒｖｅｒ}は、分散ＦＳサーバ２のＭＴＴＦを表し、Ｆ．Ｏ．Ｔｉｍｅ_{ｓｅｒｖｅｒ}は、分散ＦＳサーバ２をフェイルオーバ（Ｆａｉｌ Ｏｖｅｒ）する際に要する時間（Ｆ．Ｏ．Ｔｉｍｅ）を表す。本実施形態では、ＭＴＴＦとしては、サーバ管理テーブルＴ５における分散ＦＳサーバのＭＴＴＦ Ｃ５０５の平均値を用い、Ｆ．Ｏ．Ｔｉｍｅ_{ｓｅｒｖｅｒ}としては、例えば、サーバ管理テーブルＴ５の起動時間Ｃ５０６の値に所定の時間（例えば、１分）を加算した値を用いている。なお、ＭＴＴＦ、Ｆ．Ｏ．Ｔｉｍｅの見積もり方法は、これに限られず、他の方法を用いてもいい。

このようにＬＵ２００の数を最大サーバ数と同数とすることで、分散ボリューム１００に含まれる最大のサーバ数（限界のサーバ数）まで、分散ＦＳサーバ２間でＬＵ２００をリバランスすることが可能となる。また、分散ＦＳサーバの稼働率に基づいて、ＬＵ数を決定しているので、分散ストレージシステム０で使用する分散ＦＳサーバによる、使用するサーバの台数の信頼性に応じて最適なＬＵ数を動的に計算することができる。なお、稼働率に基づいて最大サーバ数を決定するようにしていたが、これに限られず、例えば、予め設定された固定の最大サーバ数を使用してもよい。

ステップＳ１３０：管理プログラムＰ２１は、分散ボリューム作成要求のボリュームサイズを作成ＬＵ数で除算することにより、１ＬＵ当たりのデータ容量を算出する。次いで、管理プログラムＰ２１は、算出されたデータ容量のＬＵを、作成ＬＵ数分だけ作成するようにストレージアレイ６に指示して、ＬＵ２００を作成する。次いで、管理プログラムＰ２１は、作成した複数のＬＵ２００を稼働中の分散ＦＳサーバ２に均等となるように割当て、割り当てた情報に対応するように、分散ボリューム管理テーブルＴ４とＬＵ割当管理テーブルＴ７を更新する。

ステップＳ１４０：管理プログラムＰ２１は、分散ＦＳサーバ２上のストレージ接続プログラムＰ５に対し、ステップＳ１３０で割り当てたＬＵ２００に接続するよう指示する。指示を受けたストレージ接続プログラムＰ５は、管理プログラムＰ２１から指示された、ストレージアレイ６のＬＵＮに対応するＬＵ２００を、指定されたマウントポイントにマウントする。

ステップＳ１５０：管理プログラムＰ２１は、分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１に分散ボリューム１００を作成するように指示する。この結果、分散ＦＳ制御プログラムＰ１は、分散ボリューム１００に対応する構成を、分散ボリューム構成管理テーブルＴ０を更新することにより、分散ボリューム１００を作成する。

ステップＳ１６０：管理プログラムＰ２１は、分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１に作成した分散ボリューム１００のサービスを開始するように指示する。この結果、分散ＦＳ制御プログラムＰ１は、作成された分散ボリューム１００のサービスを開始する。

上記したボリューム作成処理によると、ストレージアレイ６に適切な数のＬＵ２００を有する分散ボリューム１００を作成することができ、後述する処理により、リバランス処理を適切に行うことができる。

次に、管理サーバ５によるリバランス処理について説明する。

図１８は、第１実施形態に係るリバランス処理のフローチャートである。

リバランス処理においては、リバランス制御プログラムＰ２２（厳密には、リバランス制御プログラムＰ２２を実行する管理サーバ５のＣＰＵ５１）は、分散ＦＳサーバの増設や減設に伴って、分散ＦＳサーバ２間でＬＵ２００を再割り当てすることで分散ＦＳサーバ２間の負荷のリバランスを実現する。ＬＵ再割り当て時には、分散ボリューム１００のＬＵ２００の構成を引き継ぎ、ＬＵ２００に対して既に割り当てられたハッシュ値の範囲を引き継ぐことで、分散ＦＳサーバ２間でネットワークを介したＬＵ２００のデータを移行することを不要とすることができる。

リバランス処理では、リバランス制御プログラムＰ２２は、分散ボリューム１００を構成するＬＵ２００が分散ＦＳサーバ２間で均等となるように分散し、かつ分散ＦＳサーバ２間での負荷が均等となるようにＬＵ２００の再割り当てを行う。この際、リバランス制御プログラムＰ２２は、負荷分散に加え、分散ＦＳサーバ２間のＬＵ２００の再割り当て時間を最小化するように、移行するＬＵ数が少なくなるように再割り当てするＬＵ２００を決定する。

ステップＳ２１０：リバランス制御プログラムＰ２２は、管理者または管理プログラムＰ２１から、リバランスの対象とする分散ボリューム名（対象ボリューム名）を含んだ分散ボリュームリバランス要求を受け付ける。

ステップＳ２２０：リバランス制御プログラムＰ２２は、データリバランスを実現するために必要な、ＬＵ２００を再割り当てするプラン（ＬＵ再割り当てプラン）を作成するＬＵ再割り当てプラン作成処理を実行する。ＬＵ再割り当てプランは、分散ボリューム１００を構成するＬＵ２００を管理する分散ＦＳサーバ２間で、ＬＵ２００の数が均等となるように、かつ分散ＦＳサーバ２間の負荷が均等となるように決定される。なお、リバランス制御プログラムＰ２２は、リバランスするＬＵ２００の指定が要求に含まれている場合は、要求の内容をそのまま再割り当てプランに使用する。ＬＵ再割り当てプラン作成処理の詳細は、図１９を用いて後述する。

ステップＳ２３０：リバランス制御プログラムＰ２２は、分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１に、リバランス対象の分散ボリューム１００のサービス（分散ボリューム１００のデータに対するアクセス）を一時的に停止するように指示する。この結果、分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１は、リバランス対象の分散ボリューム１００のサービスを一時的に停止する。

ステップＳ２４０：リバランス制御プログラムＰ２２は、ステップＳ２２０で作成されたＬＵ再割り当てプランに基づいて、分散ＦＳサーバ２に対するＬＵ２００の再割り当てを行う。具体的には、リバランス制御プログラムＰ２２は、ＬＵ再割り当てプランにおいて、ＬＵ２００の移行元となっている分散ＦＳサーバ２のストレージ接続プログラムＰ５に対して、該当するＬＵ２００との接続を解除する指示を行う。この結果、ストレージ接続プログラムＰ５は、該当するＬＵ２００との接続を解除する。その後、リバランス制御プログラムＰ２２は、ＬＵの移行先となっている分散ＦＳサーバ２のストレージ接続プログラムＰ５に、該当するＬＵ２００と接続し、そのＬＵ２００を指定されたパスにマウントする指示を行う。指示を受けたストレージ接続プログラムＰ５は、該当するＬＵ２００を接続し、指定されたパスにマウントする。次いで、リバランス制御プログラムＰ２２は、分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１に、分散ボリューム構成管理テーブルＴ０のＬＵのパスに対応するサーバＩＤ Ｃ２の値を移行先のサーバＩＤに更新するように指示する。分散ＦＳ制御プログラムＰ１は、分散ボリューム構成管理テーブルＴ０のＬＵのパスに対応するサーバＩＤ Ｃ２の値を移行先のサーバＩＤに更新する。これにより、ＬＵ２００と、管理する分散ＦＳサーバ２との対応関係が反映される。次いで、リバランス制御プログラムＰ２２は、ＬＵ割当管理テーブルＴ７のサーバＩＤ Ｃ７０３を移行先のサーバＩＤに更新する。

ステップＳ２５０：リバランス制御プログラムＰ２２は、分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１に、分散ボリューム１００のサービスを再開するように指示する。分散ＦＳ制御プログラムＰ１は、分散ボリューム１００のサービスを再開する。この後、クライアントサーバ１は、分散ボリューム１００に再接続する時に、分散ＦＳサーバ２の分散ＦＳ制御プログラムＰ１から送信される、ＬＵ２００と分散ＦＳサーバ２との対応関係を受け取り、その対応関係に基づいて、ハッシュ管理テーブルＴ８を更新する。

次に、ステップＳ２２０におけるＬＵ再割り当てプラン作成処理について説明する。

図１９は、第１実施形態に係るＬＵ再割り当てプラン作成処理のフローチャートである。図１９のＬＵ再割り当てプラン作成処理は、分散ＦＳサーバ２の増設時におけるＬＵ再割り当てプラン作成処理である。

リバランス制御プログラムＰ２２は、分散ＦＳサーバの増設時に分散ボリューム１００内、および分散ＦＳサーバ間の負荷の均等化を考慮し、ＬＵ再割り当てプランを作成する。この際、リバランス時間を短縮するために、できるだけ少ないＬＵ２００を移行するようにしている。

ステップＳ３１０：リバランス制御プログラムＰ２２は、以下の式（２）を用いて、各分散ボリュームについて、増設した分散ＦＳサーバに移行するＬＵ数を決定する。

増設サーバへ移行するＬＵ数＝ｆｌｏｏｒ（対象の分散ボリュームの全ＬＵ数／増設後のサーバ数）・・・（２）
ここで、ｆｌｏｏｒは、整数以下の切り下げを意味する。

ステップＳ３２０：リバランス制御プログラムＰ２２は、ストレージアレイ６からＬＵ統計情報テーブルＴ３を取得し、ＬＵ統計情報テーブルＴ３に基づいて、各分散ＦＳサーバ２の負荷を計算する。次いで、リバランス制御プログラムＰ２２は、複数の分散ＦＳサーバ２を負荷の高い順にソートする。次いで、リバランス制御プログラムＰ２２は、それぞれのボリュームについて、ステップＳ３１０で求めた移行するＬＵ数のＬＵ２００を、負荷の高い分散ＦＳサーバ２から順番にラウンドロビンでそのボリュームのＬＵを選択して再割り当てＬＵとし、再割り当てＬＵと、再割り当てＬＵの移行元の分散ＦＳサーバ２と、移行先（割り当て先）の分散ＦＳサーバ２との情報を含むＬＵ再割り当てプランを作成する。このＬＵ再割り当てプランに従うＬＵ再割り当てを行うことにより、各分散ＦＳサーバ２の負荷を均等化するようにすることができる。

なお、図１９では、分散ＦＳサーバ２の増設時のＬＵ再割り当てプラン作成処理を示したが、分散ＦＳサーバ２の減設時には、ステップＳ３１０の処理を省略し、リバランス制御プログラムＰ２２は、減設する分散ＦＳサーバ２のＬＵ２００の移行先の分散ＦＳサーバ２を決定する。この場合、リバランス制御プログラムＰ２２は、ストレージアレイ６からＬＵ統計情報テーブルＴ３を取得し、ＬＵ統計情報テーブルＴ３に基づいて各分散ＦＳサーバ２の負荷を計算し、各分散ＦＳサーバ２を負荷の低い順にソートする。次いで、リバランス制御プログラムＰ２２は、減設する分散ＦＳサーバ２の再割り当てするＬＵ２００の移行先として、負荷の低い分散ＦＳサーバ２から順番に割り当て、再割り当てＬＵと、再割り当てＬＵの移行元の分散ＦＳサーバ２と、移行先の分散ＦＳサーバ２との情報を含むＬＵ再割り当てプランを作成する。このＬＵ再割り当てプランに従うＬＵ再割り当てを行うことにより、各分散ＦＳサーバ２の負荷を均等化するようにすることができる。

また、上記した分散ＦＳサーバ２の増設時又は減設時のＬＵ再割り当てプラン作成処理を行った後、リバランス制御プログラムＰ２２は、ＬＵ統計情報テーブルＴ３に基づいて、作成したＬＵ再割り当てプラン作成処理を行った場合に想定される分散ＦＳサーバ２の負荷を計算し、各分散ＦＳサーバ２の負荷を均一化するようにＬＵの再割り当てを行うＬＵ再割り当てプランを更新するようにしてもよい。

次に、管理プログラムＰ２１が提供する分散ボリューム作成管理用の管理インターフェースの画面について説明する。

図２０は、第１実施形態に係る分散ボリューム構成変更画面の一例である。分散ボリューム構成変更画面Ｉ１は、例えば、管理サーバ５に接続されたディスプレイ５５に表示される。

管理者は、分散ボリューム構成変更画面Ｉ１を通して、分散ボリューム１００のデータリバランスを実行させることができる。

分散ボリューム構成変更画面Ｉ１は、構成変更表示領域Ｉ１０と、現在負荷表示領域Ｉ６０と、変更後負荷表示領域Ｉ７０と、決定ボタンＩ８０と、キャンセルボタンＩ９０と、を含む。

構成変更表示領域Ｉ１０は、分散ボリューム１００のＬＵの移行先を表示、選択するための領域であり、分散ボリューム表示領域Ｉ１１と、サーバ表示領域Ｉ１２と、ストレージアレイ表示領域Ｉ１３と、ＬＵＮ表示領域Ｉ１４と、移行先サーバ選択表示領域Ｉ１５と、を有する。分散ボリューム表示領域Ｉ１１には、分散ボリュームＩＤが表示される。サーバ表示領域Ｉ１２には、分散ボリュームを構成するＬＵ２００を管理する分散ＦＳサーバ２のサーバＩＤが表示される。ストレージアレイ表示領域Ｉ１３には、ＬＵ２００を格納するストレージアレイ６のストレージアレイＩＤが表示される。ＬＵＮ表示領域Ｉ１４には、ＬＵ２００のＬＵ ＩＤが表示される。移行先サーバ選択表示領域Ｉ１５には、移行先の分散ＦＳサーバ２のサーバＩＤが表示される。ここで、表示される移行先の分散ＦＳサーバ２のサーバＩＤは、例えば、リストボックスにより管理者により選択されたサーバＩＤである。

現在負荷表示領域Ｉ６０には、現在（構成変更前）の分散ＦＳサーバ２の負荷が表示される。表示される負荷は、例えば、リバランス制御プログラムＰ２２により算出される。変更後負荷表示領域Ｉ７０には、構成変更表示領域Ｉ１０に示される構成に変更した場合における各分散ＦＳサーバ２の負荷の見積もりが表示される。表示される負荷の見積もりは、例えば、リバランス制御プログラムＰ２２により算出される。この変更後負荷表示領域Ｉ７０によると、管理者は、構成変更後の各分散ＦＳサーバ２の負荷の状況を容易且つ適切に把握することができる。

決定ボタンＩ８０は、構成変更表示領域Ｉ１０に設定された構成変更（リバランス）を実行させる指示を受け付ける。決定ボタンＩ８０が押下されると、リバランス制御プログラムＰ２２は、構成変更表示領域Ｉ１０に示される構成となるように、図１８に示すリバランス処理を行う。キャンセルボタンＩ９０は、構成変更（リバランス）の実行をキャンセルする指示を受け付ける。キャンセルボタンＩ９０が押下されると、リバランス制御プログラムＰ２２は、リバランスの実行をキャンセルする。

＜第２実施形態＞
次に、第２実施形態に係る計算機システムの一例としての分散ストレージシステム０Ａの概要について説明する。

分散ストレージシステム０Ａは、疑似乱数データ配置アルゴリズムを用いた分散オブジェクトストレージである。ここで、疑似乱数データ配置アルゴリズムとは、データのハッシュ値を用いデータを偏りがないように配置するためのアルゴリズムであり、このようなアルゴリズムとしてはＣＲＵＳＨ（Controlled Replication Under Scalable-Hashing）等がある。また、疑似乱数データ配置アルゴリズムを用いたオブジェクトストレージの例としてＣＲＵＳＨを用いたＣｅｐｈがある。

分散ストレージシステム０Ａにおいては、複数のオブジェクトストレージサーバ１０１によって分散オブジェクトストレージを構成し、各オブジェクトストレージサーバ１０１は、共有ストレージ（ストレージアレイ６）を使用している。分散ストレージシステム０Ａでは、細粒度のＬＵ２００（本実施形態では、ストレージデバイスともいう。論理単位領域の一例）を複数作成し、複数のＬＵ２００により、オブジェクトプール３００（図２１参照：共有領域の一例）を構成する。分散ストレージシステム０Ａは、第１実施形態と同様に、分散サーバ（オブジェクトストレージサーバ１０１）の増減設に伴って、分散サーバ間でＬＵ２００を移行することで、ネットワーク経由のデータ転送がない、高速なリバランスを実現する。

図２１は、第２実施形態に係る分散ストレージシステムの処理の概要を示す図である。なお、第１実施形態に係る分散ストレージシステムと同様な構成部分については、同一の符号を付し、重複する説明を省略する。図２１は、分散ストレージシステム０Ａにおけるサーバ増設時のリバランス処理の概要を示す。

分散ストレージシステム０Ａは、分散ストレージシステム０における分散ＦＳサーバ２に代えて、オブジェクトストレージサーバ１０１（１０１Ａ～１０１Ｅ）を備え、分散ボリューム１００に代えてオブジェクトプール３００を備える。分散ストレージシステム０Ａは、ユーザデータを格納するためのオブジェクトプール３００をクライアントサーバ１Ａに対して提供する。オブジェクトプール３００は、複数のオブジェクトストレージサーバ１１０に提供されている複数のＬＵ２００をたばねて構成されている。図２１の例では、オブジェクトプール３００は、オブジェクトストレージサーバ１０１Ａ（サーバＡ）を含む一台以上のオブジェクトストレージサーバ１０１に提供されているＬＵ２００から構成される。

分散ストレージシステム０Ａ、オブジェクトプール３００に格納するユーザデータを、例えば、オブジェクト（データ単位の一例）を単位として格納する。分散ストレージシステム０Ａは、疑似乱数データ配置アルゴリズムを用いて、オブジェクトを、オブジェクトストレージサーバ１０１間で均等化するように分散（均等分散という）する。

オブジェクトストレージサーバ１０１は、ユーザデータを、ストレージアレイ６内に作成された細粒度のＬＵ２００に格納する。管理サーバ５は、リバランス時にＬＵ２００を割り当てるオブジェクトストレージサーバ１０１を変更する。この際、管理サーバ５は、オブジェクトプール３００を構成するＬＵの構成情報（ＬＵ割当管理テーブルＴ７（図１３参照））において、ＬＵを担当するサーバ（担当サーバ）を変更することで、リバランス前後の各ＬＵが変わらないようにする。この結果、ネットワーク経由のデータ移行は不要となり、高速データリバランスを実現できる。

図２１は、オブジェクトストレージサーバ１０１Ａ～１０１Ｄにより構成されている分散ストレージシステム０Ａに対して、オブジェクトストレージサーバ１０１Ｅ（オブジェクトストレージサーバＥ）を増設した場合において、オブジェクトストレージサーバ１０１Ａ～１０１Ｄが管理しているＬＵ２００（ＬＵ１～ＬＵ２０）によって構成するオブジェクトプール３００のデータをリバランスするリバランス処理の概要を示している。

分散ストレージシステム０Ａは、オブジェクトストレージサーバ１０１Ｅが増設された場合、オブジェクトストレージサーバ１０１Ａ～１０１Ｄに割り当てられたＬＵ２００（ＬＵ１～ＬＵ２０）の一部のＬＵ２００（ＬＵ５，ＬＵ１０，ＬＵ１５，ＬＵ２０）を、オブジェクトストレージサーバ１０１Ｅに再割り当てする。この際、オブジェクトプール３００におけるＬＵの構成を変更せず、各ＬＵ２００が変わらないようにする。分散ストレージシステム０Ａは、オブジェクトストレージサーバ１０１Ｅに再割り当て後、分散オブジェクトストレージ制御プログラムＰ４１は、クライアントサーバ１Ａに再割り当て後のデータ配置を通知し、クライアントサーバ１Ａからのデータアクセスをリバランス後のデータ配置に対応するオブジェクトストレージサーバ１０１に切り替える。このようにすることで、分散ストレージシステム０Ａ、オブジェクトストレージサーバ１０１間のデータ移行についてのネットワーク転送を伴うことなく、増設したオブジェクトストレージサーバ１０１Ｅへのデータリバランスを実現することができる。

以上説明したように、第２実施形態に係る分散ストレージシステム０Ａでは、オブジェクトプール３００を、ストレージアレイ６内における多数（例えば、オブジェクトストレージサーバ１０１の数より多い数）のＬＵ２００で作成しておき、オブジェクトストレージサーバ１０１の構成が変わった際に、ＬＵ２００をオブジェクトストレージサーバ１０１間で再割り当てすることで、ネットワーク経由のデータ移行処理を不要とする。この結果、データリバランスの処理に要する時間を大幅に減らすことができる。クライアントサーバ１Ａに対して論理的な記憶領域である分散ボリューム１００を提供する分散ファイルシステムを構成する。

管理サーバ５の構成は、基本的には、図９に示す管理サーバ５の構成と同様である。また、ストレージアレイ６の構成は、基本的には、図６のストレージアレイ６の構成と同様である。なお、管理サーバ５及びストレージアレイ６のテーブルのＬＵ ＩＤのフィールドは、ストレージデバイスのＩＤ（ストレージデバイスＩＤ）が格納されるフィールドとなる。

次に、オブジェクトストレージサーバ１０１の構成について説明する。

図２２は、第２実施形態に係るオブジェクトストレージサーバ１０１の構成図である。なお、図３の分散ＦＳサーバ２と同様な構成については、同一の符号を付し、重複する説明を省略する場合がある。

オブジェクトストレージサーバ１０１は、他のオブジェクトストレージサーバ１０１と共に、クライアントサーバ１Ａに対して論理的な記憶領域であるオブジェクトプール３００を提供するオブジェクトストレージを構成する。

オブジェクトストレージサーバ１０１のメモリ２２は、分散ＦＳ制御プログラムＰ１に代えてオブジェクトストレージ制御プログラムＰ４１を記憶し、分散ボリューム構成管理テーブルＴ０に代えてオブジェクトストレージ制御テーブルＴ９を記憶する。

オブジェクトストレージ制御プログラムＰ４１は、他のオブジェクトストレージサーバ１０１と協調し、オブジェクトプール３００をクライアントサーバ１Ａに提供する。

オブジェクトストレージ制御テーブルＴ９は、オブジェクトストレージの制御情報を格納する。オブジェクトストレージ制御テーブルＴ９のエントリは、図４に示す分散ボリューム構成管理テーブルＴ０のエントリにおける分散ボリュームＩＤ Ｃ１に代えてストレージプールＩＤのフィールドを有する。ストレージプールＩＤのフィールドには、ストレージプール３００を識別する識別子（ストレージプールＩＤ）が格納される。

次に、第２実施形態に係るクライアントサーバ１Ａの構成について説明する。なお、図１４に示すクライアントサーバ１と同様な構成には同一の符号を付し、重複する説明を省略する場合がある。

クライアントサーバ１Ａのメモリ１２は、分散ＦＳクライアントプログラムＰ３２に代えて、オブジェクトストレージクライアントプログラムＰ５２を格納する。また、メモリ１２は、ハッシュ管理テーブルＴ８に代えて、ストレージデバイスＩＤ管理テーブルＴ１０を格納する。

オブジェクトストレージクライアントプログラムＰ５２は、オブジェクトプール３００に接続するための制御を行う。ストレージデバイスＩＤ管理テーブルＴ１０は、オブジェクトプール３００へのアクセスに必要なストレージデバイス（ＬＵ２００）のＩＤ（ストレージデバイスＩＤ）を管理するためのテーブルである。ストレージデバイスＩＤ管理テーブルＴ１０の詳細については、図２４を用いて後述する。

次に、ストレージデバイスＩＤ管理テーブルＴ１０の構成について詳細に説明する。

図２４は、第２実施形態に係るストレージデバイスＩＤ管理テーブルの構成図である。

ストレージデバイスＩＤ管理テーブルＴ１０は、クライアントサーバ１Ａ上のオブジェクトストレージクライアントプログラムＰ５２がオブジェクトストレージサーバ１０１で管理されているオブジェクトにアクセスするためのストレージデバイスＩＤを管理する。ストレージデバイスＩＤ管理テーブルＴ１０は、オブジェクトプールＩＤ Ｃ１００１と、サーバＩＤ Ｃ１００２と、ストレージデバイス ＩＤ Ｃ１００３とのフィールドを含む。

オブジェクトプールＩＤ Ｃ１００１には、オブジェクトプール３００のＩＤ（オブジェクトプールＩＤ）が格納される。サーバＩＤ Ｃ１００２には、エントリに対応するデオブジェクトプール３００のオブジェクトを格納するオブジェクトストレージサーバ１０１の識別子（サーバＩＤ）が格納される。サーバＩＤ Ｃ１００２には、オブジェクトプール３００のデータを管理する全てのオブジェクトストレージサーバ１０１に対応するサーバＩＤが格納される。ストレージデバイスＩＤ Ｃ１００３には、オブジェクトプール３００を構成するストレージデバイスのＩＤ（ストレージデバイスＩＤ）が格納される。ストレージデバイスＩＤ Ｃ１００３には、エントリに対応するオブジェクトプール３００を構成する全てのストレージデバイスのストレージデバイスＩＤが格納される。

第２実施形態に係る分散ストレージシステム０Ａにおけるデータ格納処理の概要を説明する。

図２５は、第２実施形態に係る分散ストレージシステム０Ａにおけるデータ格納処理の概要を示す図である。

図２５は、クライアントサーバ１Ａが、オブジェクトストレージサーバ１０１Ａ～１０１Ｃにより構成されたオブジェクトプール３００にオブジェクトＯ１～Ｏ３（ＯｂｊＡ～ＯｂｊＣ）を格納する場合の処理の概要を示している。

クライアントサーバ１において、格納対象のオブジェクトをオブジェクトプール３００に格納する際には、クライアントサーバ１のオブジェクトストレージクライアントプログラムＰ５２が、以下の式（３）により、各ストレージデバイスに対するスコアを計算する。

スコア＝ＨＡＳＨ（オブジェクトＩＤ，ストレージデバイスＩＤ）・・・（３）
ここで、ＨＡＳＨは、２値を引数とするハッシュ関数であり、疑似乱数データ配置アルゴリズムに使用可能な関数である。

次いで、オブジェクトストレージクライアントプログラムＰ５２は、ストレージデバイスの中で算出されたスコアが最も高いストレージデバイス（ＬＵ２００に対応）に対して、格納対象のオブジェクトを格納する。ここで、ＨＡＳＨは、引数に対して確率的に均等に分散された値を算出することができるため、ストレージデバイス間で均等となるように負荷と容量とを分散することができる。

第２実施形態に係る分散ストレージシステム０Ａにおいては、上記した第１実施形態に係る分散処理システム０と同様な処理（図１７～図１９）を実行する。なお、各処理において、分散ＦＳ制御プログラムＰ１はオブジェクトストレージ制御プログラムＰ４１と、分散ボリューム構成管理テーブルＴ０はオブジェクトストレージ制御テーブルＴ９と、分散ＦＳクライアントプログラムＰ３２は、オブジェクトストレージクライアントプログラムＰ５２と、ハッシュ管理テーブルＴ８はストレージデバイスＩＤ管理テーブルＴ１０と、分散ＦＳサーバ２はオブジェクトストレージサーバ１０１と、分散ボリューム１００はオブジェクトプール３００と、ＬＵ－ＩＤはストレージデバイスＩＤと、それぞれ読み替えればよい。

以上、本発明の実施形態を説明したが、以上の実施形態は、本発明を分かりやすく説明するために詳細に説明したものであり、本発明は、必ずしも説明した全ての構成を備えるものに限定されるものではない。ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。図の構成は説明上必要と考えられるものを示しており、製品上必ずしも全ての構成を示しているとは限らない。

また、実施形態では、各サーバとして物理サーバを使用した構成にて説明したが、これに限られず、仮想マシンを用いたクラウドコンピューティング環境においても本発明は適用可能である。クラウドコンピューティング環境は、クラウド提供者により抽象化されたシステム・ハードウェア構成上において、仮想マシン／コンテナを運用する構成となる。この場合、実施形態で示したサーバは仮想マシン／コンテナにより実現でき、ストレージアレイ６はクラウド提供者が提供するブロックストレージサービスにより実現できる。

０，０Ａ…分散ストレージシステム、１，１Ａ…クライアントサーバ、２…分散ＦＳサーバ、５…管理サーバ、６…ストレージアレイ、７…ＦＥネットワーク、８…ＢＥネットワーク、９…ＳＡＮ、１００…分散ボリューム、１０１…オブジェクトストレージサーバ、３００…オブジェクトプール

Claims (9)

1. 複数の分散サーバと、複数の分散サーバによってアクセス可能な共有領域と、管理装置と、を備える分散ストレージシステムであって、
   前記共有領域は、複数の論理単位領域で構成され、それぞれの論理単位領域を管理する分散サーバが決められており、データ単位の識別子から計算したハッシュ値に基づいて前記データ単位を格納する論理単位領域が決定され、決定された論理単位領域を管理する分散サーバが前記共有領域の前記データ単位に対するＩ／Ｏ処理を行うようになっており、
   前記複数の分散サーバは、論理単位領域と前記論理単位領域を管理する分散サーバとの対応関係を記憶し、
   前記管理装置のプロセッサは、
   前記論理単位領域を管理する分散サーバを変更する際に、前記分散サーバの前記対応関係を、変更後の論理単位領域と前記論理単位領域を管理する分散サーバとの対応関係に更新させる
   分散ストレージシステム。
2. 前記プロセッサは、
   前記共有領域を、前記分散ストレージシステムの分散サーバの数よりも多い論理単位領域で構成されるように生成する
   請求項１に記載の分散ストレージシステム。
3. 前記プロセッサは、
   前記分散ストレージシステムの前記分散サーバの数が変更される場合に、前記共有領域における前記論理単位領域の数を変更せずに、各分散サーバが管理する論理単位領域の数が均等化されるように、前記共有領域における一部の論理単位領域を管理する分散サーバを変更する
   請求項２に記載の分散ストレージシステム。
4. 前記プロセッサは、
   前記共有領域において、所定の稼働率以上を実現できる最大の分散サーバ数である最大サーバ数を算出し、前記最大サーバ数以下の数の論理単位領域により構成される共有領域を生成する
   請求項２に記載の分散ストレージシステム。
5. 前記プロセッサは、
   前記共有領域の論理単位領域を管理する前記分散サーバの平均故障時間に基づいて稼働率を推定することにより、前記最大サーバ数を算出する
   請求項４に記載の分散ストレージシステム。
6. 前記プロセッサは、
   前記最大サーバ数と同数の論理単位領域により構成される共有領域を生成する
   請求項４に記載の分散ストレージシステム。
7. 複数の共有領域を有し、
   前記プロセッサは、前記分散ストレージシステムの各分散サーバの負荷が均等化されるように、論理単位領域を管理する分散サーバを変更する
   請求項１に記載の分散ストレージシステム。
8. 前記分散サーバは、
   前記共有領域に対するデータを利用するクライアントサーバに対して、前記論理単位領域と前記論理単位領域を管理する分散サーバとの対応関係を通知する
   請求項１に記載の分散ストレージシステム。
9. 複数の分散サーバと、複数の分散サーバによってアクセス可能な共有領域と、管理装置と、を備える分散ストレージシステムによる管理方法であって、
   前記共有領域は、複数の論理単位領域で構成され、それぞれの論理単位領域を管理する分散サーバが決められており、データ単位の識別子から計算したハッシュ値に基づいて前記データ単位を格納する論理単位領域が決定され、決定された論理単位領域を管理する分散サーバが前記共有領域の前記データ単位に対するＩ／Ｏ処理を行うようになっており、
   前記複数の分散サーバは、論理単位領域と前記論理単位領域を管理する分散サーバとの対応関係を記憶し、
   前記管理装置は、
   前記論理単位領域を管理する分散サーバを変更する際に、前記分散サーバの前記対応関係を、変更後の論理単位領域と前記論理単位領域を管理する分散サーバとの対応関係に更新させる
   管理方法。