JP7332488B2 - ストレージシステム及びストレージシステムの制御方法 - Google Patents

Description

本発明は、ストレージシステム及びストレージシステムの制御方法に関する。

ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）およびビッグデータ解析のための大容量データの格納先として、容量および性能を安価に拡張できるスケールアウト型の分散ストレージシステムが広まっている。ストレージに格納するデータの増加にともない、ノード当たりの格納データ容量も増え、サーバ障害回復時のリビルド時間が長期化し、信頼性および可用性の低下を招いている。

特許文献１では、多数のサーバから構成される分散ファイルシステム（Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ：以下、分散ＦＳと言う）において、内蔵ディスクに格納したデータをサーバ間で冗長化し、サーバ障害時に他のサーバにサービスのみをフェールオーバする方式が開示されている。障害サーバに格納したデータは、フェールオーバ後に、他のサーバに格納した冗長データから回復される。

特許文献２では、共有ストレージを用いたＮＡＳ（Ｎｅｔｗｏｒｋ Ａｔｔａｃｈｅｄ Ｓｔｏｒａｇｅ）システムにおいて、サーバ障害時に、ユーザデータを格納した共有ストレージのＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）に対するアクセスパスを、障害サーバからフェールオーバ先のサーバに切り替えることで、サービスをフェールオーバする方法が開示されている。本方式では、サーバ障害回復後に、回復したサーバにＬＵのアクセスパスを切り替えることで、リビルドなしの障害回復が可能であるが、特許文献１に示した分散ストレージシステムのように、サーバ数に比例したユーザボリュームの容量および性能のスケールアウトが実現できない。

米国特許出願公開第２０１５／１２１１３１号明細書 米国特許第７９３０５８７号明細書

特許文献１に示されるような多数のサーバ間でデータを冗長化する分散ファイルシステムでは、障害回復時にリビルドが必要となる。リビルドでは、復旧したサーバに対し、他のサーバ上の冗長データから、ネットワーク経由でデータをリビルドする必要があり、障害回復時間が長期化する。

また、特許文献２に示される方式では、共有ストレージを用いることでユーザデータをサーバ間で共有でき、ＬＵのパス切り替えによるサービスのフェールオーバおよびフェールバックが可能となる。この場合、データは共有ストレージにあるため、サーバ障害時のリビルドを不要とし、障害回復時間を短くすることができる。

しかしながら、全サーバをまたがって巨大なストレージプールを構成する分散ファイルシステムでは、フェールオーバ後の負荷分散が課題となる。分散ファイルシステムでは、サーバ間で負荷を均等分散するため、障害サーバのサービスを他のサーバに引き継いだ場合、フェールオーバ先のサーバの負荷が他のサーバの２倍になる。その結果、フェールオーバ先のサーバが過負荷となり、アクセス応答時間が悪化する。

また、フェールオーバ中のＬＵは、他のサーバからアクセスすることができない状態となる。分散ファイルシステムでは、サーバをまたがりデータを分散配置するため、ひとつでもアクセスできないＬＵがあれば、ストレージプール全体のＩＯに影響する。ストレージプールを構成するサーバ数が増えた場合に、フェールオーバの頻度が増え、ストレージプールの可用性が低下する。

本発明は、上記事情に鑑みなされたものであり、その目的は、フェールオーバによる負荷集中を低減することが可能なストレージシステムを提供することにある。

上記目的を達成するため、第１の観点に係るストレージシステムは、複数のサーバと、
前記複数のサーバが共用してデータを格納できる共有ストレージとを備えたストレージシステムにおいて、前記複数のサーバは、それぞれ、１または複数の論理ノードを備え、前記複数のサーバの複数の論理ノードは、ストレージプールを提供するとともに、前記ストレージプールに入出力されるユーザデータを、いずれかの論理ノードが処理して前記共有ストレージに入出力する分散ファイルシステムを形成し、前記論理ノードは、前記サーバ間で移動可能である。

本発明によれば、フェールオーバによる負荷集中を低減することができる。

図１は、第１実施形態に係るストレージシステムのフェールオーバ方法の一例を示すブロック図である。 図２は、第１実施形態に係るストレージシステムの構成例を示すブロック図である。 図３は、図２の分散ＦＳサーバのハードウェア構成例を示すブロック図である。 図４は、図２の共有ストレージアレイのハードウェア構成例を示すブロック図である。 図５は、図２の管理サーバのハードウェア構成例を示すブロック図である。 図６は、図２のホストサーバのハードウェア構成例を示すブロック図である。 図７は、図１の論理ノード制御情報の一例を示す図である。 図８は、図３のストレージプール管理テーブルの一例を示す図である。 図９は、図３のＲＡＩＤ制御テーブルの一例を示す図である。 図１０は、図３のフェールオーバ制御テーブルの一例を示す図である。 図１１は、図４のＬＵ制御テーブルの一例を示す図である。 図１２は、図５のＬＵ管理テーブルの一例を示す図である。 図１３は、図５のサーバ管理テーブルの一例を示す図である。 図１４は、図５のアレイ管理テーブルの一例を示す図である。 図１５は、第１実施形態に係るストレージシステムのストレージプール作成処理の一例を示すフローチャートである。 図１６は、第１実施形態に係るストレージシステムのフェールオーバ処理の一例を示すシーケンス図である。 図１７は、第１実施形態に係るストレージシステムのフェールバック処理の一例を示すシーケンス図である。 図１８は、第１実施形態に係るストレージシステムのストレージプール拡張処理の一例を示すフローチャートである。 図１９は、第１実施形態に係るストレージシステムのストレージプール縮小処理の一例を示すフローチャートである。 図２０は、第１実施形態に係るストレージシステムのストレージプール作成画面の一例を示す図である。 図２１は、第２実施形態に係るストレージシステムのフェールオーバ方法の一例を示すブロック図である。 図２２は、第２実施形態に係るストレージシステムのストレージプール作成処理の一例を示すフローチャートである。

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

また、以下の説明では、「ａａａテーブル」の表現にて各種情報を説明することがあるが、各種情報は、テーブル以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ａａａテーブル」を「ａａａ情報」と呼ぶこともできる。

また、以下の説明では、「ネットワークＩ／Ｆ」は、１以上の通信インタフェースデバイスを含んでよい。１以上の通信インタフェースデバイスは、１以上の同種の通信インタフェースデバイス（例えば、１以上のＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ））であってもよいし、２以上の異種の通信インタフェースデバイス（例えば、ＮＩＣとＨＢＡ（Ｈｏｓｔ Ｂｕｓ Ａｄａｐｔｅｒ））であってもよい。

また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部または一部が１つのテーブルであってもよい。

また、以下の説明では、記憶装置は、物理的な不揮発性の記憶デバイス（例えば、補助記憶デバイス（例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）またはＳＣＭ（Ｓｔｏｒａｇｅ Ｃｌａｓｓ Ｍｅｍｏｒｙ）））である。

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

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

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

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

また、以下の説明では、分散ファイルシステムは、１以上の物理的な計算機（ノード）およびストレージアレイを含む。１以上の物理的な計算機は、物理的なノードと物理的なストレージアレイとのうちの少なくとも１つを含んでよい。少なくとも１つの物理的な計算機が、仮想的な計算機（例えば、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ））を実行してもよいし、ＳＤｘ（Ｓｏｆｔｗａｒｅ－Ｄｅｆｉｎｅｄ ａｎｙｔｈｉｎｇ）を実行してもよい。ＳＤｘとしては、例えば、ＳＤＳ（Ｓｏｆｔｗａｒｅ Ｄｅｆｉｎｅｄ Ｓｔｏｒａｇｅ）（仮想的なストレージ装置の一例）またはＳＤＤＣ（Ｓｏｆｔｗａｒｅ－ｄｅｆｉｎｅｄ Ｄａｔａｃｅｎｔｅｒ）を採用することができる。

図１は、第１実施形態に係るストレージシステムのフェールオーバ方法の一例を示すブロック図である。

図１において、分散ストレージシステム１０Ａは、Ｎ（Ｎは、２以上の整数）台の分散ＦＳサーバ１１Ａ～１１Ｅと、１台以上の共有ストレージを含む共有ストレージアレイ６Ａを備える。分散ストレージシステム１０Ａは、ファイルを管理するファイルシステムが論理的な管理単位に基づいてＮ台の分散ＦＳサーバ１１Ａ～１１Ｅに分散された分散ファイルシステムを構築する。各分散ＦＳサーバ１１Ａ～１１Ｅ上では、論理的な分散ファイルシステムの構成要素である論理ノード４Ａ～４Ｅが設けられ、初期状態では、各分散ＦＳサーバ１１Ａ～１１Ｅ当たり１論理ノードが存在する。論理ノードは、分散ファイルシステムの論理的な管理単位であり、ストレージプールの構成に用いられる。論理ノード４Ａ～４Ｅは、物理サーバと同様に分散ファイルシステムを構成する１ノードとして動作するが、物理的に特定の分散ＦＳサーバ１１Ａ～１１Ｅに括り付けられていない点で物理サーバと異なる。

共有ストレージアレイ６Ａは、Ｎ台の分散ＦＳサーバ１１Ａ～１１Ｅが個別に参照可能であり、異なる分散ＦＳサーバ１１Ａ～１１Ｅの論理ノード４Ａ～４Ｅを分散ＦＳサーバ１１Ａ～１１Ｅ間で引き継ぐための論理ユニット（Ｌｏｇｉｃａｌ Ｕｎｉｔ：以下、ＬＵと言うことがある）を格納する。共有ストレージアレイ６Ａは、論理ノード４Ａ～４Ｅごとにユーザデータを格納するデータＬＵ６Ａ、６Ｂ、・・・と、論理ノード４Ａ～４Ｅごとの論理ノード制御情報１２Ａ、１２Ｂ、・・・を格納する管理ＬＵ１０Ａ、１０Ｂ、・・・を有する。各論理ノード制御情報１２Ａ、１２Ｂ、・・・は、各分散ＦＳサーバ１１Ａ～１１Ｅ上で論理ノード４Ａ～４Ｅを構成するために必要な情報である。

分散ファイルシステム１０Ａは１つ以上の分散ＦＳサーバから構成され、ストレージプールをホストサーバに提供する。このとき、各ストレージプールには、１つ以上の論理ノードが割り当てられる。図１では、ストレージプール２Ａは、論理ノード４Ａ～４Ｃを含む１つ以上の論理ノードから構成され、ストレージプール２Ｂは、論理ノード４Ｄ、４Ｅを含む１つ以上の論理ノードから構成された例を示した。分散ファイルシステムは、複数のホストから参照可能な１以上のストレージプールをホストに提供する。例えば、分散ファイルシステムは、ストレージプール２Ａをホストサーバ１Ａ、１Ｂに対して提供し、ストレージプール２Ｂをホストサーバ１Ｃに対して提供する。

ストレージプール２Ａ、２Ｂともに、共有ストレージアレイ６Ａに格納された複数のデータＬＵ６Ａ、６Ｂ、・・・を、各分散ＦＳサーバ１１Ａ～１１Ｅ内でＲＡＩＤ８Ａ～８Ｅ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ）構成とすることでデータを冗長化する。冗長化は、論理ノード４Ａ～４Ｅごとに行い、分散ＦＳサーバ１１Ａ～１１Ｅ間でのデータの冗長化は行わない。

分散ストレージシステム１０Ａは、各分散ＦＳサーバ１１Ａ～１１Ｅの障害発生時にはフェールオーバを実施し、その分散ＦＳサーバ１１Ａ～１１Ｅの障害回復後にフェールバクを実施する。このとき、分散ストレージシステム１０Ａは、同一のストレージプールを構成する分散ＦＳサーバ以外の分散ＦＳサーバをフェールオーバ先として選択する。

例えば、分散ＦＳサーバ１１Ａ～１１Ｃは、同一のストレージプール２Ａを構成し、分散ＦＳサーバ１１Ｄ、１１Ｅは、同一のストレージプール２Ｂを構成する。このとき、分散ＦＳサーバ１１Ａ～１１Ｃのいずれかに障害が発生した場合、その障害が発生した分散ＦＳサーバの論理ノードのフェールオーバ先として、分散ＦＳサーバ１１Ｄ、１１Ｅのいずれかを選択する。例えば、分散ＦＳサーバ１１Ａの障害発生時には、分散ＦＳサーバ１１Ａの論理ノード４Ａを分散ＦＳサーバ１１Ｄにフェールオーバすることで、サービスを継続する。

具体的には、ハードウェア障害またはソフトウェア障害などが原因で分散ＦＳサーバ１１Ａが応答不能となり、分散ＦＳサーバ１１Ａが管理するデータへのアクセスが不可となったものとする（Ａ１０１）。

次に、分散ＦＳサーバ１１Ｂ、１１Ｃのうち１台が分散ＦＳサーバ１１Ａの障害を検知する。障害を検知した分散ＦＳサーバ１１Ｂ、１１Ｃは、ストレージプール２Ａに含まれない分散ＦＳサーバ１１Ｄ、１１Ｅのうち、最も負荷の低い分散ＦＳサーバ１１Ｄをフェールオーバ先に選出する。分散ＦＳサーバ１１Ｄは、分散ＦＳサーバ１１Ａの論理ノード４Ａに割当てられたデータＬＵ６Ａと管理ＬＵ１０ＡのＬＵパスを自らに切り替え、アタッチする（Ａ１０２）。ここで言うアタッチとは、分散ＦＳサーバ１１Ａのプログラムが該当するＬＵにアクセス可能な状態とする処理である。ＬＵパスは、ＬＵにアクセスするためのアクセスパスである。

次に、分散ＦＳサーバ１１Ｄは、Ａ１０２でアタッチされたデータＬＵ６Ａと管理ＬＵ１０Ａを用いて、論理ノード４Ａを分散ＦＳサーバ１１Ｄ上で起動し、サービスを再開する（Ａ１０３）。

次に、分散ＦＳサーバ１１Ｄは、分散ＦＳサーバ１１Ａの障害回復後に、論理ノード４Ａを停止し、論理ノード４Ａに割当てられたデータＬＵ６Ａと管理ＬＵ１０Ａをデタッチする（Ａ１０４）。ここで言うデタッチとは、分散ＦＳサーバ１１Ｄの全ての書き込みデータをＬＵに反映した上で、分散ＦＳサーバ１１ＤのプログラムからＬＵにアクセスできない状態とする処理である。その後、分散ＦＳサーバ１１Ａは、論理ノード４Ａに割当てられたデータＬＵ６Ａと管理ＬＵ１０Ａを分散ＦＳサーバ１１Ａにアタッチする。

次に、分散ＦＳサーバ１１ＡはＡ１０４でアタッチしたデータＬＵ６Ａと管理ＬＵ１０Ａを用いて、論理ノード４Ａを分散ＦＳサーバ１１Ａ上で起動し、サービスを再開する（Ａ１０５）。

以上説明したように、上述した第１実施形態によれば、ＬＵパス切り替えによるフェールオーバとフェールバックにより、分散ＦＳサーバ１１Ａ～１１Ｅ間でデータ冗長化が不要となり、サーバ障害時のリビルドも不要となる。その結果、分散ＦＳサーバ１１Ａの障害発生時の回復時間を減らすことができる。

また、上述した第１実施形態によれば、障害が発生した分散ＦＳサーバ１１Ａと同一のストレージプール２Ａを構成する分散ＦＳサーバ１１Ｂ、１１Ｃ以外の分散ＦＳサーバ１１Ｄをフェールオーバ先として選択することにより、分散ＦＳサーバ１１Ｂ、１１Ｃの負荷集中を防止することができる。

なお、上述した第１実施形態では、分散ＦＳサーバがＲＡＩＤ制御を有する例を示したが、これは例示に過ぎない。他に、共有ストレージアレイ６ＡがＲＡＩＤ制御を有し、ＬＵを冗長化する構成も可能である。

図２は、第１実施形態に係るストレージシステムの構成例を示すブロック図である。
図２において、分散ストレージシステム１０Ａは、管理サーバ５、Ｎ個の分散ＦＳサーバ１１Ａ～１１Ｃ、・・・および１つまたは複数の共有ストレージアレイ６Ａ、６Ｂを備える。１つまたは複数のホストサーバ１Ａ～１Ｃが分散ストレージシステム１０Ａに接続する。

ホストサーバ１Ａ～１Ｃ、管理サーバ５および分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、フロントエンド（ＦＥ）ネットワーク９を介して接続されている。分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、バックエンド（ＢＥ）ネットワーク１９を介して互いに接続されている。分散ＦＳサーバ１１Ａ～１１Ｃ、・・・および共有ストレージアレイ６Ａ、６Ｂは、ＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１８を介して接続されている。

各ホストサーバ１Ａ～１Ｃは、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・のクライアントである。各ホストサーバ１Ａ～１Ｃは、ネットワークＩ／Ｆ３Ａ～３Ｃを備える。各ホストサーバ１Ａ～１Ｃは、ネットワークＩ／Ｆ３Ａ～３Ｃを介してＦＥネットワーク９に接続し、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・に対してファイルＩ／Ｏを発行する。このとき、ＮＦＳ（Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ）、ＣＩＦＳ（Ｃｏｍｍｏｎ Ｉｎｔｅｒｎｅｔ Ｆｉｌｅ Ｓｙｓｔｅｍ）、ＡＦＰ（Ａｐｐｌｅ Ｆｉｌｉｎｇ Ｐｒｏｔｏｃｏｌ）などのネットワークを介したファイルＩ／Ｏインタフェースのためのいくつかのプロトコルを用いることができる。

管理サーバ５は、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・および共有ストレージアレイ６Ａ、６Ｂの管理用のサーバである。管理サーバ５は、管理ネットワークＩ／Ｆ７を備える。管理サーバ５は、管理ネットワークＩ／Ｆ７を介してＦＥネットワーク９に接続し、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・と共有ストレージアレイ６Ａ、６Ｂに対して管理要求を発行する。管理要求の通信形態として、ＳＳＨ（Ｓｅｃｕｒｅ Ｓｈｅｌｌ）を介したコマンド実行またはＲＥＳＴ ＡＰＩ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ）などを使用する。管理サーバ５は、管理者に対し、ＣＬＩ（Ｃｏｍｍａｎｄ Ｌｉｎｅ Ｉｎｔｅｒｆａｃｅ）、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）またはＲＥＳＴ ＡＰＩなどの管理インタフェースを提供する。

分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、各ホストサーバ１Ａ～１Ｃに対して論理的な記憶領域であるストレージプールを提供する分散ファイルシステムを構成する。各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、ＦＥ Ｉ／Ｆ１３Ａ～１３Ｃ、・・・、ＢＥ Ｉ／Ｆ１５Ａ～１５Ｃ、・・・、ＨＢＡ１６Ａ～１６Ｃ、・・・およびＢＭＣ（Ｂａｓｅｂｏａｒｄ Ｍａｎａｇｅｍｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ）１７Ａ～１７Ｃ、・・・をそれぞれ備える。各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、ＦＥ Ｉ／Ｆ１３Ａ～１３Ｃ、・・・を介してＦＥネットワーク９に接続し、各ホストサーバ１Ａ～１ＣからのファイルＩ／Ｏと、管理サーバ５からの管理要求を処理する。各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、ＨＢＡ１６Ａ～１６Ｃ、・・・を介してＳＡＮ１８に接続し、ストレージアレイ６Ａ、６Ｂにユーザデータと制御情報を格納する。各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、ＢＥ Ｉ／Ｆ１５Ａ～１５Ｃ、・・・を介してＢＥネットワーク１９に接続し、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・間で通信する。各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、ＢＭＣ（Ｂａｓｅｂｏａｒｄ Ｍａｎａｇｅｍｅｎｔ Ｃｏｎｔｒｏｌｌｅｒ）１７Ａ～１７Ｃ、・・・を介して正常時および障害発生時の外部から電源操作を可能とする。

ＳＡＮ１８の通信プロトコルとして、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）、ｉＳＣＳＩまたはＮｏｎ－Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ Ｅｘｐｒｅｓｓ（ＮＶＭｅ）などが使用でき、通信媒体としてＦＣ（ファイバチャネル）またはＥｔｈｅｒｎｅｔを使用できる。ＢＭＣ１７Ａ～１７Ｃ、・・・の通信プロトコルとして、Ｉｎｔｅｌｌｉｇｅｎｔ Ｐｌａｔｆｏｒｍ Ｍａｎａｇｅｍｅｎｔ Ｉｎｔｅｒｆａｃｅ （ＩＰＭＩ）が使用できる。ＳＡＮ１８は、ＦＥネットワーク９から分離している必要はない。ＦＥネットワーク９とＳＡＮ１８の両方を併合することが可能である。

ＢＥネットワーク１９について、各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・は、ＢＥ Ｉ／Ｆ１５Ａ～１５Ｃを使用し、ＢＥネットワーク１９を介して他の分散ＦＳサーバ１１Ａ～１１Ｃ、・・・と通信する。このＢＥネットワーク１９は、メタデータを交換したり、他の様々な目的に使用することができる。ＢＥネットワーク１９は、ＦＥネットワーク９から分離している必要はない。ＦＥネットワーク９とＢＥネットワーク１９の両方を併合することが可能である。

共有ストレージアレイ６Ａ、６Ｂは、各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・が管理するユーザデータおよび制御情報を格納するための論理的な記憶領域としてＬＵを各分散ＦＳサーバ１１Ａ～１１Ｃ、・・・に提供する。

なお、図２では、ホストサーバ１Ａ～１Ｃと管理サーバ５を分散ＦＳサーバ１１Ａ～１１Ｃ、・・・とは物理的に別のサーバとして示したが、これは例示に過ぎない。他にも、ホストサーバ１Ａ～１Ｃと分散ＦＳサーバ１１Ａ～１１Ｃ、・・・で同じサーバを共有してもよいし、管理サーバ５と分散ＦＳサーバ１１Ａ～１１Ｃ、・・・で同じサーバを共有してもよい。

図３は、図２の分散ＦＳサーバのハードウェア構成例を示すブロック図である。なお、図３では、図２の分散ＦＳサーバ１１Ａを例にとるが、他の分散ＦＳサーバ１１Ｂ、１１Ｃ、・・・も同様に構成することができる。

図３において、分散ＦＳサーバ１１Ａは、ＣＰＵ２１Ａ、メモリ２３Ａ、ＦＥ Ｉ／Ｆ１３Ａ、ＢＥ Ｉ／Ｆ１５Ａ、ＨＢＡ１６Ａ、ＢＭＣ１７Ａおよび記憶装置２７Ａを備える。

メモリ２３Ａは、ストレージデーモンプログラムＰ１、監視デーモンプログラムＰ３、メタデータサーバデーモンプログラムＰ５、プロトコル処理プログラムＰ７、フェールオーバ制御プログラムＰ９、ＲＡＩＤ制御プログラムＰ１１、ストレージプール管理テーブルＴ２、ＲＡＩＤ制御テーブルＴ３およびフェールオーバ制御テーブルＴ４を保持する。

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

ストレージデーモンプログラムＰ１、監視デーモンプログラムＰ３およびメタデータサーバデーモンプログラムＰ５は、他の分散ＦＳサーバ１１Ｂ、１１Ｃ、・・・と協調し、分散ファイルシステムを構成する。以下、ストレージデーモンプログラムＰ１、監視デーモンプログラムＰ３およびメタデータサーバデーモンプログラムＰ５を総称して、分散ＦＳ制御デーモンと呼ぶ。分散ＦＳ制御デーモンは、分散ＦＳサーバ１１Ａ上で、分散ファイルシステムの論理的な管理単位である論理ノード４Ａを構成し、他の分散ＦＳサーバ１１Ｂ、１１Ｃ、・・・と協調して分散ファイルシステムを実現する。

ストレージデーモンプログラムＰ１は、分散ファイルシステムのデータ格納を処理する。ストレージデーモンプログラムＰ１は、論理ノードごとに１つ以上割り当てられ、それぞれがＲＡＩＤ Ｇｒｏｕｐごとのデータの読み書きを担当する。

監視デーモンプログラムＰ３は、分散ファイルシステムを構成する分散ＦＳ制御デーモン群と定期的に通信し、生死監視を行う。監視デーモンプログラムＰ３は、分散ファイルシステム全体で事前に決められた１つ以上のプロセス数動作し、分散ＦＳサーバ１１Ａによっては存在しない場合もある。

メタデータサーバデーモンプログラムＰ５は、分散ファイルシステムのメタデータを管理する。ここで言うメタデータとは、分散ファイルシステムのファイル・ディレクトリの名前空間、Ｉｎｏｄｅ番号、アクセス権限情報およびＱｕｏｔａなどを指す。メタデータサーバデーモンプログラムＰ５も、分散ファイルシステム全体で事前に決められた１つ以上のプロセス数のみ動作し、分散ＦＳサーバ１１Ａによっては存在しない場合もある。

プロトコル処理プログラムＰ７は、ＮＦＳまたはＳＭＢなどのネットワーク通信プロトコルの要求を受信し、分散ファイルシステムへのファイルＩ／Ｏへと変換する。

フェールオーバ制御プログラムＰ９は、分散ストレージシステム１０Ａ内の１台以上の分散ＦＳサーバ１１Ａ～１１Ｃ、・・・からＨＡ（Ｈｉｇｈ ａｖａｉｌａｂｉｌｉｔｙ）クラスタを構成する。ここで言うＨＡクラスタは、ＨＡクラスタを構成するあるノードに障害が発生した際に、障害ノードのサービスを他のサーバに引き継ぐシステム構成を指す。フェールオーバ制御プログラムＰ９は、同一の共有ストレージアレイ６Ａ、６Ｂに対してアクセス可能な２台以上の分散ＦＳサーバ１１Ａ～１１Ｃ、・・・に対してＨＡクラスタを構築する。ＨＡクラスタの構成は、管理者が設定してもいいし、フェールオーバ制御プログラムＰ９が自動で設定してもいい。フェールオーバ制御プログラムＰ９は、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・の生死を監視し、ノード障害を検知した際に、障害ノードの分散ＦＳ制御デーモンを他の分散ＦＳサーバ１１Ａ～１１Ｃ、・・・にフェールオーバする制御を行う。

ＲＡＩＤ制御プログラムＰ１１は、共有ストレージアレイ６Ａ、６Ｂが提供するＬＵを冗長化し、ＬＵ障害発生時にＩＯを継続可能とする。各種テーブル類については、図８から図１０を用いて後述する。

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

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

記憶装置２７Ａは、分散ＦＳサーバ１１Ａで使用する各種プログラムを格納した不揮発性記憶媒体である。記憶装置２７Ａは、ＨＤＤ、ＳＳＤまたはＳＣＭを使用することができる。

図４は、図２の共有ストレージアレイのハードウェア構成例を示すブロック図である。なお、図４では、図２の共有ストレージアレイ６Ａを例にとるが、他の共有ストレージアレイ６Ｂも同様に構成することができる。
図４において、ストレージアレイ６Ａは、ＣＰＵ２１Ｂ、メモリ２３Ｂ、ＦＥ Ｉ／Ｆ１３、ストレージＩ／Ｆ２５、ＨＢＡ１６および記憶装置２７Ｂを有する。

メモリ２３Ｂは、ＩＯ制御プログラムＰ１３、アレイ管理プログラムＰ１５およびＬＵ制御テーブルＴ５を保持する。

ＣＰＵ２１Ｂは、ＩＯ制御プログラムＰ１３およびアレイ管理プログラムＰ１５に従ってデータ処理することによって、所定の機能を提供する。

ＩＯ制御プログラムＰ１３は、ＨＢＡ１６経由で受信したＬＵに対するＩＯ要求を処理し、記憶装置２７Ｂに格納したデータの読み書きを行う。アレイ管理プログラムＰ１５は、管理サーバ５から受信したＬＵ管理要求に従い、ストレージアレイ６Ａ内のＬＵの作成、拡張、縮小および削除を行う。ＬＵ制御テーブルＴ５は、図１１を用いて後述する。

ＦＥ Ｉ／Ｆ１３およびＨＢＡ１６は、それぞれＳＡＮ１８およびＦＥネットワーク９に接続するための通信インタフェースデバイスである。

記憶装置２７Ｂは、ストレージアレイ６Ａで使用する各種プログラムに加え、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・が格納したユーザデータおよび制御情報を記録する。ＣＰＵ２１Ｂは、ストレージＩ／Ｆ２５を介して記憶装置２７Ｂのデータを読み書きできる。ＣＰＵ２１ＢとストレージＩ／Ｆ２５との間の通信には、ＦＣ（ファイバチャネル）、ＳＡＴＡ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）、ＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）またはＩＤＥ（Ｉｎｔｅｇｒａｔｅｄ Ｄｅｖｉｃｅ Ｅｌｅｃｔｒｏｎｉｃｓ）などのインタフェースが用いられる。記憶装置２７Ｂの記憶媒体には、ＨＤＤ、ＳＳＤ、ＳＣＭ、フラッシュメモリ、光ディスクまたは磁気テープなどのような複数の種類の記憶媒体を使用することができる。

図５は、図２の管理サーバのハードウェア構成例を示すブロック図である。
図５において、管理サーバ５は、ＣＰＵ２１Ｃ、メモリ２３Ｃ、管理ネットワークＩ／Ｆ７および記憶装置２７Ｃを備える。管理プログラムＰ１７は、入力装置２９およびディスプレイ３１に接続されている。

メモリ２３Ｃは、管理プログラムＰ１７、ＬＵ管理テーブルＴ６、サーバ管理テーブルＴ７およびアレイ管理テーブルＴ８を保持する。

ＣＰＵ２１Ｃは、管理プログラムＰ１７に従ってデータ処理することによって、所定の機能を提供する。

管理プログラムＰ１７は、管理者から管理ネットワークＩ／Ｆ７を介して受信した管理要求に従い、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・およびストレージアレイ６Ａ、６Ｂに対して構成変更要求を発行する。ここで言う管理者からの管理要求とは、ストレージプールの作成・削除・拡大・縮小および論理ノードのフェールオーバ・フェールバックなどを含む。分散ＦＳサーバＦＳ１１Ａ～１１Ｃ、・・・への構成変更要求とは、ストレージプールの作成・削除・拡大・縮小および論理ノードのフェールオーバ・フェールバックなどを含む。ストレージアレイ６Ａ、６Ｂへの構成変更要求とは、ＬＵ作成・削除・拡張・縮小およびＬＵパスの追加、削除、変更を含む。各種テーブルは、図１１から図１３を用いて後述する。

管理ネットワークＩ／Ｆ７は、ＦＥネットワーク９に接続するための通信インタフェースデバイスである。記憶装置２７Ｃは、管理サーバ５で使用する各種プログラムを格納した不揮発性記憶媒体である。記憶装置２７Ｃには、ＨＤＤ、ＳＳＤまたはＳＣＭなどを使用することができる。入力装置２９は、キーボード、マウスまたはタッチパネルを含み、利用者（あるいは管理者）の操作を受け付ける。ディスプレイ３１には、管理インタフェースの画面などが表示される。

図６は、図２のホストサーバのハードウェア構成例を示すブロック図である。なお、図６では、図２のホストサーバ１Ａを例にとるが、他のホストサーバ１Ｂ、１Ｃも同様に構成することができる。

図６において、ホストサーバ１Ａは、ＣＰＵ２１Ｄ、メモリ２３Ｄ、ネットワークＩ／Ｆ３Ａおよび記憶装置２７Ｄを有する。

メモリ２３Ｄは、アプリケーションプログラムＰ２１およびネットワークファイルアクセスプログラムＰ２３を保持する。

アプリケーションプログラムＰ２１は、分散ストレージシステム１０Ａを利用してデータ処理を行う。アプリケーションプログラムＰ２１は、例えば、Ｒｅｌａｔｉｏｎａｌ Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ（ＲＤＭＳ）またはＶＭ Ｈｙｐｅｒｖｉｓｏｒなどのプログラムである。

ネットワークファイルアクセスプログラムＰ２３は、分散ＦＳサーバ１１Ａ～１１Ｃ、・・・に対してファイルＩ／Ｏを発行して分散ＦＳサーバ１１Ａ～１１Ｃ、・・・に対するデータの読み書きを行う。ネットワークファイルアクセスプログラムＰ２３は、ネットワーク通信プロトコルにおいて、クライアント側の制御を提供するが、これに限定されるものではない。

図７は、図１の論理ノード制御情報の一例を示す図である。なお、図７では、図１の論理ノード制御情報１２Ａを例にとるが、他の論理ノード制御情報１２Ｂ、・・・も同様に構成することができる。

図７において、論理ノード制御情報１２Ａは、図１の分散ＦＳサーバ１１Ａの分散ＦＳ制御デーモンが管理する論理ノードの制御情報を格納する。

論理ノード制御情報１２Ａは、論理ノードＩＤ Ｃ１１、ＩＰアドレスＣ１２、監視デーモンＩＰ Ｃ１３、認証情報Ｃ１４、デーモンＩＤ Ｃ１５およびデーモン種別Ｃ１６のエントリを含む。

論理ノードＩＤ Ｃ１１は、分散ストレージシステム１０Ａ内で一意に識別可能な論理ノードの識別子を格納する。

ＩＰアドレスＣ１２は、論理ノードＩＤ Ｃ１１で示された論理ノードのＩＰアドレスを格納する。ＩＰアドレスＣ１２は、図２のＦＥネットワーク９およびＢＥネットワーク１９それぞれのＩＰアドレスを格納する。

監視デーモンＩＰ Ｃ１３は、分散ファイルシステムの監視デーモンプログラムＰ３のＩＰアドレスを格納する。分散ＦＳ制御デーモンは、監視デーモンＩＰ Ｃ１３に格納されたＩＰアドレスを介して監視デーモンプログラムＰ３と通信することで、分散ＦＳに参加する。

認証情報Ｃ１４は、分散ＦＳ制御デーモンが監視デーモンプログラムＰ３と接続する際の認証情報を格納する。この認証情報には、例えば、監視デーモンプログラムＰ３から取得した公開鍵を用いることができるが、他の認証情報を用いてもいい。

デーモンＩＤ Ｃ１５は、論理ノードＩＤ Ｃ１１で示された論理ノードを構成する分散ＦＳ制御デーモンのＩＤを格納する。デーモンＩＤ Ｃ１５は、ストレージデーモン、監視デーモンおよびメタデータサーバデーモンそれぞれに対し管理し、１つの論理ノードに対し複数のデーモンＩＤ Ｃ１５を持つことができる。

デーモン種別Ｃ１６は、デーモンＩＤ Ｃ１５の各デーモンの種別を格納する。デーモン種別として、ストレージデーモン、メタデータサーバデーモンおよび監視デーモンの３つのうちいずれかを格納できる。

なお、本実施形態では、ＩＰアドレスＣ１２および監視デーモンＩＰ Ｃ１３にＩＰアドレスを使用しているが、これは例示に過ぎない。他にホスト名を用いた通信を行うことも可能である。

図８は、図３のストレージプール管理テーブルの一例を示す図である。
図８において、ストレージプール管理テーブルＴ２は、分散ＦＳ制御デーモンがストレージプールの構成を管理するための情報を格納する。分散ファイルシステムを構成するすべての分散ＦＳサーバ１１Ａ～１１Ｅは、互いに通信し、同一の内容を持つストレージプール管理テーブルＴ２を保持する。

ストレージ管理テーブルＴ２は、プールＩＤ Ｃ２１、冗長化レベルＣ２２および所属ストレージデーモンＣ２３のエントリを含む。

プールＩＤ Ｃ２１は、図１の分散ストレージシステム１０Ａ内で一意に識別可能なストレージプールの識別子を格納する。プールＩＤ Ｃ２１は、新規に作成されるストレージプールに対し、分散ＦＳ制御デーモンが生成する。

冗長化レベルＣ２２は、プールＩＤ Ｃ２１に示されたストレージプールのデータの冗長化レベルを格納する。冗長化レベルＣ２２には、「無効」、「二重化」、「三重化」および「Ｅｒａｓｕｒｅ Ｃｏｄｅ」のいずれかを指定できるが、本実施形態では、分散ＦＳサーバ１１Ａ～１１Ｅ間では冗長化を行わないため、「無効」を指定する。

所属ストレージデーモンＣ２３は、プールＩＤ Ｃ２１に示されたストレージプールを構成するストレージデーモンプログラムＰ１の識別子を１つ以上格納する。所属ストレージデーモンＣ２３は、ストレージプール作成時に管理プログラムＰ１７が設定する。

図９は、図３のＲＡＩＤ制御テーブルの一例を示す図である。
図９において、ＲＡＩＤ制御テーブルＴ３は、ＲＡＩＤ制御プログラムＰ１１がＬＵを冗長化するための情報を格納する。ＲＡＩＤ制御プログラムＰ１１は、起動時に管理サーバ５と通信し、ＬＵ管理テーブルＴ６の内容に基づき、ＲＡＩＤ制御テーブルＴ３を作成する。ＲＡＩＤ制御プログラムＰ１１は、ＲＡＩＤ制御テーブルＴ３の内容に従い、共有ストレージアレイ６Ａが提供するＬＵからＲＡＩＤ Ｇｒｏｕｐを構築し、分散ＦＳ制御デーモンに提供する。ここで言うＲＡＩＤ Ｇｒｏｕｐとは、データの読み書きが可能な論理的な記憶領域を指す。

ＲＡＩＤ制御テーブルＴ３は、ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ３１、冗長化レベルＣ３２、オーナノードＩＤ Ｃ３３、デーモンＩＤ Ｃ３４、ファイルパスＣ３５およびＷＷＮ Ｃ３６のエントリを含む。

ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ３１は、分散ストレージシステム１０Ａ内で一意に識別可能なＲＡＩＤ Ｇｒｏｕｐの識別子を格納する。

冗長化レベルＣ３２は、ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ３１で示されたＲＡＩＤ Ｇｒｏｕｐの冗長化レベルを格納する。冗長化レベルには、ＲＡＩＤ１（ｎＤ＋ｍＤ）、ＲＡＩＤ５（ｎＤ＋１Ｐ）またはＲＡＩＤ６（ｎＤ＋２Ｐ）などのＲＡＩＤ構成を格納する。なお、ｎとｍは、それぞれＲＡＩＤ Ｇｒｏｕｐ内のデータ数と冗長化データ数を表す。

オーナノードＩＤ Ｃ３３は、ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ３１で示されたＲＡＩＤ Ｇｒｏｕｐを割り当てる論理ノードのＩＤを格納する。

デーモンＩＤ Ｃ３４は、ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ３１で示されたＲＡＩＤ Ｇｒｏｕｐを使用するデーモンのＩＤを格納する。また、ＲＡＩＤ Ｇｒｏｕｐが複数のデーモンで共有される場合、共有されることを示すＩＤである「共有」を格納する。

ファイルパスＣ３５は、ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ３１で示されたＲＡＩＤ Ｇｒｏｕｐにアクセスするためのファイルパスを格納する。ファイルパスＣ３５に格納されるファイルの種別は、ＲＡＩＤ Ｇｒｏｕｐを使用するデーモンの種別により異なる。ストレージデーモンプログラムＰ１がＲＡＩＤ Ｇｒｏｕｐを使用する場合、ファイルパスＣ３５には、デバイスファイルのパスを格納する。ＲＡＩＤ Ｇｒｏｕｐをデーモン間で共有する場合、ＲＡＩＤ Ｇｒｏｕｐをマウントしたマウントパスを格納する。

ＷＷＮ Ｃ３６は、ＳＡＮ１８でＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）を一意に識別するための識別子であるＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）を格納する。ＷＷＮ Ｃ３６は、分散ＦＳサーバ１１Ａ～１１ＥがＬＵにアクセスする際に使用する。

図１０は、図３のフェールオーバ制御テーブルの一例を示す図である。
図１０において、フェールオーバ制御テーブルＴ４は、フェールオーバ制御プログラムＰ９が論理ノードの稼働サーバを管理するための情報を格納する。ＨＡクラスタを構築する全ノードのフェールオーバ制御プログラムＰ９は、お互いに通信することで、全てのノードで同一内容のフェールオーバ制御Ｔ４を保持する。

フェールオーバ制御テーブルＴ４は、論理ノードＩＤ Ｃ４１、主サーバＣ４２、稼働サーバＣ４３およびフェールオーバ可能サーバＣ４４のエントリを含む。

論理ノードＩＤ Ｃ４１は、分散ストレージシステム１０Ａ内で一意に識別可能な論理ノードの識別子を格納する。論理ノードＩＤは、サーバの新規追加時に、管理プログラムＰ１７がサーバと対応付けられた名前を設定する。図１０では、例えば、Ｓｅｒｖｅｒ０に対して、論理ノードＩＤをＮｏｄｅ０としている。

主サーバＣ４２は、初期状態で論理ノードが稼働する各分散ＦＳサーバ１１Ａ～１１ＥのサーバＩＤを格納する。

稼働サーバＣ４３は、論理ノードＩＤ Ｃ４１で示された論理ノードが稼働する各分散ＦＳサーバ１１Ａ～１１ＥのサーバＩＤを格納する。

フェールオーバ可能サーバＣ４４は、論理ノードＩＤ Ｃ４１で示された論理ノードがフェールオーバ可能な分散ＦＳサーバ１１Ａ～１１ＥのサーバＩＤを格納する。フェールオーバ可能サーバＣ４４には、ＨＡクラスタを構成する分散ＦＳサーバ１１Ａ～１１Ｅのうち、同一のストレージプールを構成する分散ＦＳサーバを除いた分散ＦＳサーバを格納する。フェールオーバ可能サーバＣ４４は、管理プログラムＰ１７がボリューム作成時に設定する。

図１１は、図４のＬＵ制御テーブルの一例を示す図である。
図１１において、ＬＵ制御テーブルＴ５は、ＩＯ制御プログラムＰ１３およびアレイ管理プログラムＰ１５が、ＬＵの構成を管理し、ＬＵに対するＩＯ要求処理のための情報を格納する。

ＬＵ制御テーブルＴ５は、ＬＵＮ Ｃ５１、冗長化レベルＣ５２、物理デバイスＩＤ Ｃ５３、ＷＷＮ Ｃ５４、デバイス種別Ｃ５５および容量Ｃ５６のエントリを含む。

ＬＵＮ Ｃ５１は、ストレージアレイ６Ａ内のＬＵの管理番号を格納する。冗長化レベルＣ５２は、ストレージアレイ６Ａ内のＬＵの冗長化レベルを指定する。冗長レベルＣ５２に格納できる値は、ＲＡＩＤ制御テーブルＴ３の冗長化レベルＣ３２と同等となる。本実施形態では、各分散ＦＳサーバ１１Ａ～１１ＥのＲＡＩＤ制御プログラムＰ１１がＬＵを冗長化し、ストレージアレイ６Ａは冗長化を行わないため、「無効」を指定する。

記憶装置ＩＤ Ｃ５３は、ＬＵを構成する記憶装置２７Ｂの識別子を格納する。ＷＷＮ Ｃ５４は、ＳＡＮ１８でＬＵＮを一意に識別するための識別子であるＷＷＮ（Ｗｏｒｌｄ Ｗｉｄｅ Ｎａｍｅ）を格納する。ＷＷＮ Ｃ５４は、分散ＦＳサーバ１１がＬＵにアクセスする際に使用する。

デバイス種別Ｃ５５は、ＬＵを構成する記憶装置２７Ｂの記憶媒体の種別を格納する。デバイス種別Ｃ５５には、「ＳＣＭ」、「ＳＳＤ」または「ＨＤＤ」などのデバイス種別を示す記号を格納する。容量Ｃ５６は、ＬＵの論理容量を格納する。

図１２は、図５のＬＵ管理テーブルの一例を示す図である。
図１２において、ＬＵ管理テーブルＴ６は、管理プログラムＰ１７が、分散ストレージシステム１０Ａ全体で共有するＬＵの構成を管理するための情報を格納する。管理プログラムＰ１７は、アレイ管理プログラムＰ１５およびＲＡＩＤ制御プログラムＰ１１と連携し、ＬＵの作成・削除および論理ノードへの割当てを行う。

ＬＵ管理テーブルＴ６は、ＬＵ ＩＤ Ｃ６１、論理ノードＣ６２、ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ６３、冗長化レベルＣ６４、ＷＷＮ Ｃ６５および用途Ｃ６６のエントリを含む。

ＬＵ ＩＤ Ｃ６１は、分散ストレージシステム１０Ａ内で一意に識別可能なＬＵの識別子を格納する。ＬＵ ＩＤ Ｃ６１は、管理プログラムＰ１７がＬＵ作成時に生成する。論理ノードＣ６２は、ＬＵを所有する論理ノードの識別子を可能する。

ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ６３は、分散ストレージシステム１０Ａ内で一意に識別可能なＲＡＩＤ Ｇｒｏｕｐの識別子を格納する。ＲＡＩＤ Ｇｒｏｕｐ ＩＤ Ｃ６３は、管理プログラムＰ１７がＲＡＩＤ Ｇｒｏｕｐ作成時に生成する。

冗長化レベルＣ６４は、ＲＡＩＤ Ｇｒｏｕｐの冗長化レベルを格納する。ＷＷＮ Ｃ６５は、ＬＵのＷＷＮを格納する。用途Ｃ６６は、ＬＵの用途を格納する。用途Ｃ６６は、「データＬＵ」または「管理ＬＵ」を格納する。

図１３は、図５のサーバ管理テーブルの一例を示す図である。
図１３において、サーバ管理テーブルＴ７は、管理プログラムＰ１７が分散ＦＳサーバ１１Ａ～１１Ｅと通信したり、ＬＵとＲＡＩＤ Ｇｒｏｕｐの構成を決定したりするために必要な分散ＦＳサーバ１１Ａ～１１Ｅの構成情報を格納する。

サーバ管理テーブルＴ７は、サーバＩＤ Ｃ７１、接続ストレージアレイＣ７２、ＩＰアドレスＣ７３、ＢＭＣアドレスＣ７４、ＭＴＴＦ Ｃ７５および起動時間Ｃ７６のエントリを含む。

サーバＩＤ Ｃ７１は、分散ストレージシステム１０Ａ内で一意に識別可能な分散ＦＳサーバ１１Ａ～１１Ｅの識別子を格納する。

接続ストレージアレイＣ７２は、サーバＩＤ Ｃ７１で示された分散ＦＳサーバ１１Ａ～１１Ｅからアクセス可能なストレージアレイ６Ａの識別子を格納する。

ＩＰアドレスＣ７３は、サーバＩＤ Ｃ７１で示された分散ＦＳサーバ１１Ａ～１１ＥのＩＰアドレスを格納する。

ＢＭＣアドレスＣ７４は、サーバＩＤ Ｃ７１で示された分散ＦＳサーバ１１Ａ～１１Ｅの各ＢＭＣのＩＰアドレスを格納する。

ＭＴＴＦ Ｃ７５は、サーバＩＤ Ｃ７１で示された分散ＦＳサーバ１１Ａ～１１Ｅの平均故障時間ＭＴＴＦ（Ｍｅａｎ Ｔｉｍｅ Ｔｏ Ｆａｉｌｕｒｅ）を格納する。ＭＴＴＦは、例えば、サーバ種別に応じたカタログ値などを使用する。

起動時間Ｃ７６は、サーバＩＤ Ｃ７１で示された分散ＦＳサーバ１１Ａ～１１Ｅの正常状態における起動時間を格納する。管理プログラムＰ１７は、起動時間Ｃ７６を基に、フェールオーバ時間を見積もる。

なお、本実施形態では、ＩＰアドレスＣ７３およびＢＭＣアドレスＣ７４にＩＰアドレスを格納する例を示しているが、他にホスト名を使用してもよい。

図１４は、図５のアレイ管理テーブルの一例を示す図である。
図１４において、アレイ管理テーブルＴ８は、管理プログラムＰ１７がストレージアレイ６Ａと通信したり、ＬＵとＲＡＩＤ Ｇｒｏｕｐ構成を決定したりするためのストレージアレイ６Ａの構成情報を格納する。

アレイ管理テーブルＴ８は、アレイＩＤ Ｃ８１、管理ＩＰアドレスＣ８２およびＬＵＮ ＩＤ Ｃ８３のエントリを含む。

アレイＩＤ Ｃ８１は、分散ストレージシステム１０Ａ内で一意に識別可能なストレージアレイ６Ａの識別子を格納する。

管理ＩＰアドレスＣ８２は、アレイＩＤ Ｃ８１で示されたストレージアレイ６Ａの管理用ＩＰアドレスを格納する。なお、本実施形態では、ＩＰアドレスを格納する例を示しているが、他にホスト名を使用してもよい。

ＬＵ ＩＤＣ８３は、アレイＩＤ Ｃ８１で示されたストレージアレイ６Ａが提供するＬＵのＩＤを格納する。

図１５は、第１実施形態に係るストレージシステムのストレージプール作成処理の一例を示すフローチャートである。
図１５において、図５の管理プログラムＰ１７は、管理者からストレージプールの作成要求を受信すると、フェールオーバ時の負荷分散および信頼性要件に基づいて、ストレージプールを作成する。

具体的には、管理プログラムＰ１７は、管理者から新規プール名、プールサイズ、冗長化レベルおよび信頼性要件を含んだストレージプール作成要求を受信する（Ｓ１１０）。管理者は、図２０に示すストレージプール作成画面を通じて、ストレージプール作成要求を管理サーバ５に発行する。

次に、管理プログラムＰ１７は、１つ以上の分散ＦＳサーバからなるストレージプール構成候補を作成する（Ｓ１２０）。管理プログラムＰ１７は、サーバ管理テーブルＴ７を参照し、ストレージプールを構成するノードを選択する。この際、管理プログラムＰ１７は、構成ノード数を、分散ＦＳサーバ群の半分以下とすることで、ノード障害時のフェールオーバ先ノードが、同一のストレージプールの構成ノード以外にあることを保証する。

また、管理プログラムＰ１７は、サーバ管理テーブルＴ７を参照し、候補とするノードと同じストレージアレイに接続可能なノードが、同一のストレージプールの構成ノード以外にあることを保証する。

なお、構成ノード数の制限は例示に過ぎず、分散ＦＳサーバ数が少ない場合には、構成ノード数を「分散ＦＳサーバ群の数－１」としてもよい。

次に、管理プログラムＰ１７は、ストレージプールの稼働率ＫＭを見積もり、稼働率要件を満たすかどうか判断する（Ｓ１３０）。管理プログラムＰ１７は、以下の式（１）を用いてストレージプール構成候補で構成したストレージプールの稼働率ＫＭを計算する。

ただし、ＭＴＴＦ_{ｓｅｒｖｅｒ}は、分散ＦＳサーバのＭＴＴＦ、Ｆ．Ｏ．Ｔｉｍｅ_{ｓｅｒｖｅｒ}は、分散ＦＳサーバのＦ．Ｏ．時間（フェールオーバ時間）を表す。分散ＦＳサーバ１１のＭＴＴＦは、図１３のＭＴＴＦ Ｃ７５を使用し、Ｆ．Ｏ．時間は、起動時間Ｃ７６を１分大きくした値を使用する。なお、ＭＴＴＦとＦ．Ｏ．時間の見積もり方法は例示であり、その他の方法を用いてもよい。

稼働率要件は、管理者が指定した信頼性要件から設定し、例えば、高信頼が求められた場合は、稼働率の要件を０．９９９９９以上とする。

管理プログラムＰ１７は、式（１）を満たさない場合は、ストレージプール構成候補が稼働率要件を満たさないと判定し、Ｓ１４０に進み、そうでない場合はＳ１５０に進む。

稼働率要件を満たさない場合、管理プログラムＰ１７は、ストレージプール構成候補から分散ＦＳサーバを１台減らし、新たなストレージプール構成候補を作成し、Ｓ１３０に戻る（Ｓ１４０）。

稼働率要件を満たす場合、管理プログラムＰ１７は、管理インタフェースを介してストレージプール構成候補の分散ＦＳサーバ一覧を管理者に提示する（Ｓ１５０）。管理者は、分散ＦＳサーバ一覧を参照し、必要な変更を行った上で、変更後の構成をストレージプール構成として確定する。ストレージプール作成の管理インタフェースは、図２０にて後述する。

次に、管理プログラムＰ１７は、管理者が指定した冗長度レベルを満たすＲＡＩＤ Ｇｒｏｕｐ構成を決定する（Ｓ１６０）。管理プログラムＰ１７は、管理者が指定したストレージプール容量を分散ＦＳサーバ数で割った値から、分散ＦＳサーバ当たりのＲＡＩＤ Ｇｒｏｕｐ容量を算出する。管理プログラムＰ１７は、ストレージアレイ６Ａに指示し、ＲＡＩＤ Ｇｒｏｕｐを構成するＬＵを作成し、ＬＵ制御テーブルＴ５を更新する。その後、管理プログラムＰ１７は、ＲＡＩＤ制御プログラムＰ１１を介してＲＡＩＤ制御テーブルＴ３を更新し、ＲＡＩＤ Ｇｒｏｕｐを構築する。そして、管理プログラムＰ１７は、ＬＵ管理テーブルＴ６を更新する。

次に、管理プログラムＰ１７は、フェールオーバ制御プログラムＰ９と通信し、フェールオーバ制御テーブルＴ４を更新する（Ｓ１７０）。管理プログラムＰ１７は、ストレージプールを構成する分散ＦＳサーバを主サーバＣ４２とする論理ノードＩＤ Ｃ４１について、フェールオーバ可能サーバＣ４４を調べ、そのストレージプールを構成する分散ＦＳサーバが含まれている場合、その分散ＦＳサーバをフェールオーバ可能サーバＣ４４から除外する。

次に、管理プログラムＰ１７は、分散ＦＳ制御デーモンに指示し、Ｓ１６０で作成したＲＡＩＤ Ｇｒｏｕｐを使用するストレージデーモンを新たに作成する（Ｓ１８０）。その後、管理プログラムＰ１７は、分散ＦＳ制御デーモンを介して、分散ＦＳ制御情報Ｔ１とストレージプール管理テーブルＴ２を更新する。

図１６は、第１実施形態に係るストレージシステムのフェールオーバ処理の一例を示すシーケンス図である。図１６では、図１の分散ＦＳサーバ１１Ａ、１１Ｂ、１１Ｄのフェールオーバ制御プログラムＰ９および図５の管理プログラムＰ１７の処理を抜粋して示した。
図１６において、分散ＦＳサーバ１１Ａ、１１Ｂ、１１Ｄ間で定期的に通信（ハートビート）を行うことで相互に生死監視を行う（Ｓ２１０）。このとき、例えば、分散ＦＳサーバ１１Ａでノード障害が発生したものとする（Ｓ２２０）。

分散ＦＳサーバ１１Ａでノード障害が発生すると、分散ＦＳサーバ１１Ａからのハートビートが途絶える。このとき、例えば、分散ＦＳサーバ１１Ｂのフェールオーバ制御プログラムＰ９は、分散ＦＳサーバ１１Ａからのハートビートが途絶えると、分散ＦＳサーバ１１Ａの障害を検知する（Ｓ２３０）。

次に、分散ＦＳサーバ１１Ｂのフェールオーバ制御プログラムＰ９は、フェールオーバ制御テーブルＴ４を参照し、フェールオーバ可能サーバの一覧を取得する。分散ＦＳサーバ１１Ｂのフェールオーバ制御プログラムＰ９は、フェールオーバ可能サーバの全てから現在の負荷（例えば、過去２４時間のＩＯ数）を取得する（Ｓ２４０）。

次に、分散ＦＳサーバ１１Ｂのフェールオーバ制御プログラムＰ９は、Ｓ２４０で得た負荷情報から最も負荷の低い分散ＦＳサーバ１１Ｄをフェールオーバ先として選択する（Ｓ２５０）。

次に、分散ＦＳサーバ１１Ｂのフェールオーバ制御プログラムＰ９は、分散ＦＳサーバ１１ＡのＢＭＣ１７Ａに指示し、分散ＦＳサーバ１１Ａの電源を停止させる（Ｓ２６０）。

次に、分散ＦＳサーバ１１Ｂのフェールオーバ制御プログラムＰ９は、分散ＦＳサーバ１１Ｄに論理ノード４Ａを起動するよう指示する（Ｓ２７０）。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、管理サーバ５に問い合わせ、論理ノード４Ａが使用するＬＵを記載したＬＵリストを取得する（Ｓ２８０）。分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、ＲＡＩＤ制御テーブルＴ３を更新する。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、ＳＡＮ１８を介してＷＷＮ Ｃ６５を持つＬＵを検索し、分散ＦＳサーバ１１Ｄにアタッチする（Ｓ２９０）。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、ＲＡＩＤ制御プログラムＰ１１に指示し、ＲＡＩＤ Ｇｒｏｕｐを構築する（Ｓ２１００）。ＲＡＩＤ制御プログラムＰ１１は、ＲＡＩＤ制御テーブルＴ３を参照し、論理ノード４Ａが使用するＲＡＩＤ Ｇｒｏｕｐを構築する。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、論理ノード４Ａの管理ＬＵ１０Ａ内に格納された論理ノード制御情報１２Ａを参照し、論理ノード４Ａ用の分散ＦＳ制御デーモンを起動する（Ｓ２１１０）。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、分散ＦＳサーバ１１Ｄが過負荷状態となっており、かつフェールオーバから一定時間（例えば、１週間）経過後もフェールバックされない場合は、図１９に示すストレージプール縮小フローを実施し、論理ノード４Ａを分散ストレージシステム１０Ａから減設する（Ｓ２１２０）。分散ＦＳ制御デーモンは、残った分散ＦＳサーバ間でデータ容量が均等になるようにデータをリバランスすることで、負荷を均等化する。

図１７は、第１実施形態に係るストレージシステムのフェールバック処理の一例を示すシーケンス図である。図１７では、図１の分散ＦＳサーバ１１Ａ、１１Ｄのフェールオーバ制御プログラムＰ９および図５の管理プログラムＰ１７の処理を抜粋して示した。

図１７において、管理者は、障害が発生した分散ＦＳサーバ１１Ａを、サーバ交換または障害部位交換などの保守作業により障害回復を実施した後、管理インタフェースを介し管理プログラムＰ１７にノード回復を指示する（Ｓ３１０）。

次に、管理プログラムＰ１７は、ノード回復要求を管理者から受信すると、障害が発生した分散ＦＳサーバ１１Ａに対し、ノード回復指示を発行する（Ｓ３２０）。

次に、分散ＦＳサーバ１１Ａのフェールオーバ制御プログラムＰ９は、ノード回復指示を受信すると、論理ノード４Ａが動作する分散ＦＳサーバ１１Ｄに対し、論理ノード４Ａの停止指示を発行する（Ｓ３３０）。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、論理ノード４Ａの停止指示を受けると、論理ノード４Ａに割当てられた分散ＦＳ制御デーモンを停止する（Ｓ３４０）。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、論理ノード４Ａが使用していたＲＡＩＤ Ｇｒｏｕｐを停止する（Ｓ３５０）。

次に、分散ＦＳサーバ１１Ｄのフェールオーバ制御プログラムＰ９は、論理ノード４Ａが使用するＬＵを分散ＦＳサーバ１１Ｄからデタッチする（Ｓ３６０）。

次に、分散ＦＳサーバ１１Ａのフェールオーバ制御プログラムＰ９は、管理プログラムＰ１７に問い合わせ、論理ノード４Ａが使用する最新のＬＵリストを取得し、ＲＡＩＤ制御テーブルＴ３を更新する（Ｓ３７０）。

次に、分散ＦＳサーバ１１Ａのフェールオーバ制御プログラムＰ９は、論理ノード４Ａが使用するＬＵを分散ＦＳサーバ１１Ａにアタッチする（Ｓ３８０）。

次に、分散ＦＳサーバ１１Ａのフェールオーバ制御プログラムＰ９は、ＲＡＩＤ制御テーブルＴ３を参照し、ＲＡＩＤ Ｇｒｏｕｐを構成する（Ｓ３９０）。

次に、分散ＦＳサーバ１１Ａのフェールオーバ制御プログラムＰ９は、論理ノード４Ａの分散ＦＳ制御デーモンを起動する（Ｓ３１００）。

なお、図１６のＳ２１２０で論理ノード４Ａが減設されている場合は、図１７で示した処理ではなく、図１８で後述するストレージプール拡張フローで障害サーバを復旧する。

図１８は、第１実施形態に係るストレージシステムのストレージプール拡張処理の一例を示すフローチャートである。
図１８において、管理者は、分散ＦＳサーバの増設時またはストレージプールの容量不足時に、管理プログラムＰ１７に対しストレージプール拡張を指示することでストレージプール容量を拡張することができる。ストレージプール拡張が要求された場合、管理プログラムＰ１７は、新規の分散ＦＳサーバまたは指定された既存の分散ＦＳサーバに他のサーバと同容量のデータＬＵをアタッチし、ストレージプールに追加する。

具体的には、管理プログラムＰ１７は、管理インタフェースを介して管理者からのプール拡張コマンドを受信する（Ｓ４１０）。プール拡張コマンドは、新規にストレージプールに追加する分散ＦＳサーバの情報と、拡張するストレージプールＩＤを含む。管理プログラムＰ１７は、受け取った情報を基に、新規に追加する分散ＦＳサーバをサーバ管理テーブルＴ７に追加する。

次に、管理プログラムＰ１７は、ストレージアレイ６Ａに指示し、ストレージプールを構成する他の分散ＦＳサーバのデータＬＵと同じ構成のデータＬＵを作成する（Ｓ４２０）。

次に、管理プログラムＰ１７は、Ｓ４２０で作成したデータＬＵを、新規に追加する分散ＦＳサーバまたは管理者により指定された既存の分散ＦＳサーバにアタッチする（Ｓ４３０）。

次に、管理プログラムＰ１７は、ＲＡＩＤ制御プログラムＰ１１に指示し、Ｓ４３０でアタッチしたＬＵからＲＡＩＤ Ｇｒｏｕｐを構成する（Ｓ４４０）。ＲＡＩＤ制御プログラムＰ１１は、新規のＲＡＩＤ Ｇｒｏｕｐの情報をＲＡＩＤ制御テーブルＴ３に反映する。

次に、管理プログラムＰ１７は、ストレージデーモンプログラムＰ１を介して、Ｓ４４０で作成したＲＡＩＤ Ｇｒｏｕｐを管理するためのストレージデーモンを作成し、ストレージプールに追加する（Ｓ４５０）。ストレージデーモンプログラムＰ１は、論理ノード制御情報およびストレージプール管理テーブルＴ２を更新する。また、管理プログラムＰ１７は、フェールオーバ制御プログラムＰ９を介し、フェールオーバ制御テーブルＴ４のフェールオーバ可能サーバＣ４４を更新する。

次に、管理プログラムＰ１７は、分散ＦＳ制御デーモンに指示し、拡張したストレージプール内のリバランスを開始する（Ｓ４６０）。分散ＦＳ制御デーモンは、ストレージプール内の全ストレージデーモンの容量が均一となるように、ストレージデーモン間でデータ移動を行う。

図１９は、第１実施形態に係るストレージシステムのストレージプール縮小処理の一例を示すフローチャートである。
図１９において、管理者または各種制御プログラムは、管理プログラムＰ１７にストレージ縮小指示を発行することで、分散ＦＳサーバを減設することができる。

具体的には、管理プログラムＰ１７は、プール縮小コマンドを受信する（Ｓ５１０）。プール縮小コマンドは、減設する分散ＦＳサーバの名称を含む。

次に、管理プログラムＰ１７は、フェールオーバ制御テーブルＴ４を参照し、減設する分散ＦＳサーバを主サーバとする論理ノードＩＤを調べる。管理プログラムＰ１７は、分散ＦＳ制御デーモンに対し、上記論理ノードＩＤを持つ論理ノードの削除を指示する（Ｓ５２０）。分散ＦＳ制御デーモンは、指定された論理ノード上の全てのストレージデーモンに対し、他のストレージへのデータリバランスを行った上で、ストレージデーモンを削除する。また、分散ＦＳ制御デーモンは、指定された論理ノードの監視デーモンおよびメタデータサーバデーモンを、その他の論理ノードにマイグレーションする。この際、分散ＦＳ制御デーモンは、ストレージ管理テーブルＴ２と、論理ノード制御情報１２Ａを更新する。また、管理プログラムＰ１７は、フェールオーバ制御プログラムＰ９に指示し、フェールオーバ制御テーブルＴ４を更新する。

次に、管理プログラムＰ１７は、ＲＡＩＤ制御プログラムＰ１１に指示して、Ｓ５２０で削除した論理ノードが使用するＲＡＩＤ Ｇｒｏｕｐを削除し、ＲＡＩＤ制御テーブルＴ３を更新する（Ｓ５３０）。

次に、管理プログラムＰ１７は、ストレージアレイ６Ａに指示し、削除した論理ノードが使用していたＬＵを削除する（Ｓ５４０）。そして、管理プログラムＰ１７は、ＬＵ管理テーブルＴ６およびアレイ管理テーブルＴ８を更新する。

図２０は、第１実施形態に係るストレージシステムのストレージプール作成画面の一例を示す図である。ストレージプール作成インタフェースは、ストレージプール作成画面を表示させる。ストレージプール作成画面は、図５の管理サーバ５がディスプレイ３１に表示させてもよいし、クライアントがＷｅｂブラウザでＵＲＬを指定することで表示できるようにしてもよい。

図２０において、ストレージプール作成画面は、テキストボックスＩ１０、Ｉ２０、リストボックスＩ３０、Ｉ４０、入力ボタンＩ５０、サーバ一覧Ｉ６０、グラフＩ７０、決定ボタンＩ８０およびキャンセルボタンＩ９０の表示欄を備える。

テキストボックスＩ１０は、管理者が新規プール名を入力する。テキストボックスＩ２０は、管理者がストレージプールサイズを入力する。

リストボックスＩ３０は、管理者が新規に作成するストレージプールの冗長度を指定する。リストボックスＩ３０の用途には、「ＲＡＩＤ１（ｍＤ＋ｍＤ）」または「ＲＡＩＤ６（ｍＤ＋２Ｐ）」が選択でき、ｍは任意の値を使用してよい。

リストボックスＩ４０は、管理者が新規に作成するストレージプールの信頼性を指定する。リストボックスＩ４０の用途には、「高信頼（稼働率０．９９９９９以上）」、「普通（稼働率０．９９９９以上）」または「考慮しない」を選択することができる。

入力ボタンＩ５０は、管理者がテキストボックスＩ１０、Ｉ２０およびリストボックスＩ３０、Ｉ４０に入力した後に押下可能となる。入力ボタンＩ５０が押下されると、管理プログラムＰ１７は、ストレージプール作成フローを開始する。

サーバ一覧Ｉ６０は、ストレージプールを構成する分散ＦＳサーバの一覧を示すラジオボックス付きのリストである。サーバ一覧Ｉ６０は、図１５のストレージプール作成処理のＳ１５０に到達後に表示される。このリストの初期状態には、分散ストレージシステム１０Ａを構成するすべての分散ＦＳサーバに対し、管理プログラムＰ１７が作成したストレージプール構成候補のラジオボックスがオンとなる。管理者は、ラジオボックスのオン・オフを切り替えることでストレージプールの構成を変更することができる。

グラフＩ７０は、サーバ数に対する稼働率見積もりの近似曲線を示す。管理者が、入力ボタンＩ５０を押下し、サーバ一覧Ｉ６０のラジオボタンを変更したタイミングで式（１）を用いてグラフＩ７０が生成され、ストレージプール作成画面に表示される。管理者は、グラフＩ７０を参照することで、ストレージプール構成変更時の影響を確認することができる。

決定ボタンＩ８０は、管理者が押下することでストレージプールの構成を確定し、ストレージプール作成を継続する。キャンセルボタンＩ９０は、管理者が押下することでストレージプールの構成を確定し、ストレージプール作成をキャンセルする。

図２１は、第２実施形態に係るストレージシステムのフェールオーバ方法の一例を示すブロック図である。第２実施形態では、フェールオーバ単位である論理ノードを細粒度化することでフェールオーバ時の負荷分散を実現する。論理ノードを細粒度化では、１台の分散ＦＳサーバが複数の論理ノードを持つ。

図２１において、分散ストレージシステム１０Ｂは、Ｎ（Ｎは、２以上の整数）台の分散ＦＳサーバ５１Ａ～５１Ｃ、・・・と、１台以上の共有ストレージアレイ６Ａを備える。分散ＦＳサーバ５１Ａでは、論理ノード６１Ａ～６３Ａが設けられ、分散ＦＳサーバ５１Ｂでは、論理ノード６１Ｂ～６３Ｂが設けられ、分散ＦＳサーバ５１Ｃでは、論理ノード６１Ｃ～６３Ｃが設けられている。

共有ストレージアレイ６Ａは、Ｎ台の分散ＦＳサーバ５１Ａ～５１Ｃ、・・・から参照可能であり、異なる分散ＦＳサーバ５１Ａ～５１Ｃ、・・・の各論理ノード６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・を分散ＦＳサーバ５１Ａ～５１Ｃ、・・・間で引き継ぐための論理ユニットを格納する。共有ストレージアレイ６Ａは、論理ノード６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・ごとにユーザデータを格納するデータＬＵ７１Ａ～７３Ａ、・・・と、論理ノード６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・ごとの論理ノード制御情報９１Ａ～９３Ａ、・・・を格納する管理ＬＵ８１Ａ～８３Ａ、・・・を有する。各論理ノード制御情報９１Ａ～９３Ａ、・・・は、各論理ノード６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・を構成するために必要な情報である。

論理ノード６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・は、分散ファイルシステムを構成し、分散ファイルシステムは、分散ＦＳサーバ６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・から構成されるストレージプール２をホストサーバ１Ａ～１Ｃに提供する。

分散ストレージシステム１０Ｂでは、事前に設定または管理者が事前に指定した目標稼働率に対し、論理ノード６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・の粒度を十分に小さくすることで、フェールオーバ後の過負荷を回避することができる。ここで言う稼働率は、ＣＰＵおよびネットワークリソースなどの分散ＦＳサーバ５１Ａ～５１Ｃ、・・・を構成するハードウェアの使用率を指す。

分散ストレージシステム１０Ｂでは、分散ＦＳサーバ５１Ａ～５１Ｃ、・・・当たりに稼働する論理ノード数を増やすことで、論理ノード６１Ａ～６３Ａ、６１Ｂ～６３Ｂ、６１Ｃ～６３Ｃ、・・・当たりの負荷と目標稼働率の合計値が、１００％を超えないようにする。このように分散ＦＳサーバ５１Ａ～５１Ｃ、・・・当たりの論理ノード数を決めることで、目標稼働率以下の負荷で運用する場合においては、フェールオーバ後に分散ＦＳサーバ５１Ａ～５１Ｃ、・・・が過負荷となることを回避することができる。

具体的には、ハードウェア障害またはソフトウェア障害などが原因で分散ＦＳサーバ５１Ａが応答不能となり、分散ＦＳサーバ５１Ａが管理するデータへのアクセスが不可となったものとする（Ａ２０１）。

次に、分散ＦＳサーバ５１Ａ以外の分散ＦＳサーバがフェールオーバ先として選出され、フェールオーバ先として選出された分散ＦＳサーバは、分散ＦＳサーバ５１Ａの各論理ノード６１Ａ～６３Ａに割当てられたデータＬＵ７１Ａ～７３Ａと管理ＬＵ８１Ａ～８３ＡのＬＵパスを論理ノード６１Ａ～６３Ａごとに自らに切り替え、アタッチする（Ａ２０２）。

次に、フェールオーバ先として選出された各分散ＦＳサーバは、各分散ＦＳサーバが担当する論理ノード６１Ａ～６３ＡのデータＬＵ７１Ａ～７３Ａと管理ＬＵ８１Ａ～８３Ａを用いて、論理ノード６１Ａ～６３Ａを起動し、サービスを再開する（Ａ２０３）。

次に、フェールオーバ先として選出された各分散ＦＳサーバは、分散ＦＳサーバ５１Ａの障害回復後に、自らが担当する論理ノード６１Ａ～６３Ａを停止し、各論理ノード６１Ａ～６３Ａに割当てられたデータＬＵ７１Ａ～７３Ａと管理ＬＵ８１Ａ～８３Ａをデタッチする（Ａ２０４）。その後、分散ＦＳサーバ５１Ａは、各論理ノード６１Ａ～６３Ａに割当てられたデータＬＵ７１Ａ～７３Ａと管理ＬＵ８１Ａ～８３Ａを分散ＦＳサーバ５１Ａにアタッチする。

次に、分散ＦＳサーバ５１Ａは、Ａ２０４でアタッチしたデータＬＵ７１Ａ～７３Ａと管理ＬＵ８１Ａ～８３Ａを用いて、論理ノード６１Ａ～６３Ａを分散ＦＳサーバ５１Ａ上で起動し、サービスを再開する（Ａ２０５）。

図１の分散ストレージシステム１０Ａでは、分散ＦＳサーバ５１Ａ～５１Ｅ当たり１つであった初期状態での論理ノード数が、目標稼働率に従って大きくなる。その結果、分散ストレージシステム１０Ａでは、フェールオーバ先として同一ストレージプールに所属する分散ＦＳサーバが選べなかった（Ａ１０２）。これに対し、図２１の分散ストレージシステム１０Ｂでは、フェールオーバ先として同一ストレージプール２内の分散ＦＳサーバが選べる（Ａ２０２）。このため、分散ストレージシステム１０Ｂでは、ストレージプールを分割することなく、フェールオーバ後の分散ＦＳサーバの過負荷を回避することができる。

なお、分散ストレージシステム１０Ｂにおいても、図２と同様のシステム構成を用いることができ、図３～図６と同様のハードウェア構成を用いることができ、図７～図１４と同様のデータ構造を用いることができる。

図２２は、第２実施形態に係るストレージシステムのストレージプール作成処理の一例を示すフローチャートである。
図２２において、このストレージプール作成処理では、図１５のＳ１５０の処理とＳ１６０の処理との間にＳ１５５の処理が追加されている。

Ｓ１５５の処理では、管理プログラムＰ１７は、目標稼働率αに対し、分散ＦＳサーバ当たりの論理ノード数ＮＬを計算する。このとき、論理ノード数ＮＬは、以下の式（２）で与えることができる。

例えば、目標稼働率が０．７５に設定されていた場合、分散ＦＳサーバ当たりの論理ノード数は３となる。論理ノード数が３のときに稼働率０．７５で運用した場合、論理ノード当たりのリソース使用率は０．２５となるため、他の分散ＦＳサーバにフェールオーバしても、リソース使用率は１以下となる。

Ｓ１６０以降において、管理プログラムＰ１７は、分散ＦＳサーバ当たりの論理ノード数に応じた論理ノードを用意し、ＲＡＩＤ構築、フェールオーバ構成更新およびストレージデーモン作成を行う。

また、図１６のＳ２５０において、分散ストレージシステム１０Ｂは、フェールオーバ先として、ストレージプール構成によらず低負荷のサーバを指定する。また、分散ストレージシステム１０Ｂは、障害ノード上の全論理ノードに対して異なるフェールオーバ先を設定する。また、Ｓ２７０において、障害ノード上の全論理ノードのフェールオーバ先に対してデーモン起動指示を送る。

その他、分散ストレージシステム１０Ｂでは、図１７～図１９に示した処理については、分散ＦＳサーバ当たりの論理ノード数が複数となった点を除き、分散ストレージシステム１０Ａと同等である。

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

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

また、実施形態では分散ファイルシステムの論理ノードを、分散ＦＳ制御デーモンとＬＵにより構成していたが、他にも分散ＦＳサーバをＶＭとすることで論理ノードとして使用することができる。

１Ａ～１Ｃ ホストサーバ、２Ａ、２Ｂ ストレージプール、３Ａ～３Ｃ ネットワークＩ／Ｆ、５ 管理サーバ、６Ａ、６Ｂ ストレージアレイ、７ 管理ネットワークＩ／Ｆ、９ ＦＥネットワーク、１１Ａ～１１Ｅ 分散ＦＳサーバ、１３Ａ～１３Ｃ ＦＥ Ｉ／Ｆ、１５Ａ～１５Ｃ ＢＥ Ｉ／Ｆ、１６Ａ～１６Ｃ ＨＢＡ、１７Ａ～１７Ｃ ＢＭＣ、１８ ＳＡＮ、１９ ＢＥネットワーク、２１Ａ～２１Ｄ ＣＰＵ、２３Ａ～２３Ｄ メモリ、２５ ストレージＩ／Ｆ、２７Ａ～２７Ｄ 記憶装置、２９ 入力装置、３１ ディスプレイ、Ｐ１ ストレージデーモンプログラム、Ｐ３ 監視デーモンプログラム、Ｐ５ メタデータサーバデーモンプログラム、Ｐ７ プロトコル処理プログラム、Ｐ９ フェールオーバ制御プログラム、Ｐ１１ ＲＡＩＤ制御プログラム、Ｐ１３ ＩＯ制御プログラム、Ｐ１５ アレイ管理プログラム、Ｐ１７ 管理プログラム、Ｐ１９ アプリケーションプログラム、Ｐ２１ ネットワークファイルアクセスプログラム、Ｔ１ 論理ノード制御情報、Ｔ２ ストレージプール管理テーブル、Ｔ３ ＲＡＩＤ制御テーブル、Ｔ４ フェールオーバ制御テーブル、Ｔ５ ＬＵ制御テーブル、Ｔ６ ＬＵ管理テーブル、Ｔ７ サーバ管理テーブル、Ｔ８ アレイ管理テーブル

Claims (4)

1. 複数のサーバと、
   前記複数のサーバが共用してデータを格納できる共有ストレージとを備えたストレージシステムにおいて、
   前記複数のサーバは、それぞれ、１または複数の論理ノードを備え、
   前記複数のサーバの複数の論理ノードは、ストレージプールを提供するとともに、前記ストレージプールに入出力されるユーザデータを、いずれかの論理ノードが処理して前記共有ストレージに入出力する分散ファイルシステムを形成し、
   前記論理ノードは、前記サーバ間で移動可能であり、
   前記共有ストレージは、論理ノードにかかるユーザデータと、前記ユーザデータにアクセスするために用いる制御情報を保持しており、
   前記論理ノードのサーバ間移動では、ホストがサーバにアクセスするアクセスパスを移動元のサーバから移動先のサーバへ切り替えるとともに、前記移動先のサーバから前記移動にかかる論理サーバの共有ストレージ内の制御情報及びユーザデータを参照し、
   それぞれ複数の論理ノードから形成される複数のストレージプールを提供しており、
   前記移動先のサーバとして、移動にかかる論理ノードと同じストレージプールに属する論理ノードを持たないサーバを選択するストレージシステム。
2. 複数のサーバと、
   前記複数のサーバが共用してデータを格納できる共有ストレージとを備えたストレージシステムにおいて、
   前記複数のサーバは、それぞれ、１または複数の論理ノードを備え、
   前記複数のサーバの複数の論理ノードは、ストレージプールを提供するとともに、前記ストレージプールに入出力されるユーザデータを、いずれかの論理ノードが処理して前記共有ストレージに入出力する分散ファイルシステムを形成し、
   前記論理ノードは、前記サーバ間で移動可能であり、
   前記共有ストレージは、論理ノードにかかるユーザデータと、前記ユーザデータにアクセスするために用いる制御情報を保持しており、
   前記論理ノードのサーバ間移動では、ホストがサーバにアクセスするアクセスパスを移動元のサーバから移動先のサーバへ切り替えるとともに、前記移動先のサーバから前記移動にかかる論理サーバの共有ストレージ内の制御情報及びユーザデータを参照し、
   前記移動元のサーバと前記移動先のサーバは、異なるストレージプールに属するストレージシステム。
3. 複数のサーバと、
   前記複数のサーバが共用してデータを格納できる共有ストレージとを備えたストレージシステムの制御方法において、
   複数の論理ノードは、前記複数のサーバに配置されるとともに、前記複数のサーバの複数の論理ノードは、ストレージプールを提供する分散ファイルシステムを形成し、
   分散ファイルシステムを形成するいずれかの論理ノードは、前記ストレージプールに入出力されるユーザデータを処理して前記共有ストレージに入出力し、
   前記論理ノードは、前記サーバ間で移動可能であり、
   前記共有ストレージは、論理ノードにかかるユーザデータと、前記ユーザデータにアクセスするために用いる制御情報を保持しており、
   前記論理ノードのサーバ間移動では、ホストがサーバにアクセスするアクセスパスを移動元のサーバから移動先のサーバへ切り替えるとともに、前記移動先のサーバから前記移動にかかる論理サーバの共有ストレージ内の制御情報及びユーザデータを参照し、
   それぞれ複数の論理ノードから形成される複数のストレージプールを提供しており、
   前記移動先のサーバとして、移動にかかる論理ノードと同じストレージプールに属する論理ノードを持たないサーバを選択するストレージシステムの制御方法。
4. 複数のサーバと、
   前記複数のサーバが共用してデータを格納できる共有ストレージとを備えたストレージシステムの制御方法において、
   複数の論理ノードは、前記複数のサーバに配置されるとともに、前記複数のサーバの複数の論理ノードは、ストレージプールを提供する分散ファイルシステムを形成し、
   分散ファイルシステムを形成するいずれかの論理ノードは、前記ストレージプールに入出力されるユーザデータを処理して前記共有ストレージに入出力し、
   前記論理ノードは、前記サーバ間で移動可能であり、
   前記共有ストレージは、論理ノードにかかるユーザデータと、前記ユーザデータにアクセスするために用いる制御情報を保持しており、
   前記論理ノードのサーバ間移動では、ホストがサーバにアクセスするアクセスパスを移動元のサーバから移動先のサーバへ切り替えるとともに、前記移動先のサーバから前記移動にかかる論理サーバの共有ストレージ内の制御情報及びユーザデータを参照し、
   前記移動元のサーバと前記移動先のサーバは、異なるストレージプールに属するストレージシステムの制御方法。

Images