図面 (/)

技術 分散ストレージシステム、データ管理方法、及びデータ管理プログラム

出願人 株式会社日立製作所
発明者 大平良徳揚妻匡邦千葉武尊山本貴大江原寛人斎藤秀雄
出願日 2019年3月19日 (1年9ヶ月経過) 出願番号 2019-051736
公開日 2020年9月24日 (3ヶ月経過) 公開番号 2020-154626
状態 未査定
技術分野 外部記憶装置との入出力 入出力制御
主要キーワード 部分テーブル データ復元要求 読み出し要求元 Read処理 Read要求 Write要求 通信インターフェース装置 データ再配置処理
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年9月24日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

分散ストレージシステムにおいて、アクセス要求を受けた場合におけるストレージ装置間ネットワーク負荷を低減し、応答性を向上できるようにする。

解決手段

分散ストレージシステム1において、記憶デバイス113は、データ領域と、キャッシュ領域とを含み、ノードは、LUのデータがデータ領域に格納されていない未格納状態で他のノードからLUの担当移譲を受けた場合、オーナーノードとなり、オーナーノードのプロセッサ110を、担当するLUに対するリード要求受け付け、対象領域のデータがオーナーノードのデータ領域とキャッシュ領域とに格納されていない場合に、対象領域のデータを、他のノードの記憶デバイスのデータに基づいて取得し、要求元に送信するとともに、キャッシュ領域に格納するように構成する。

概要

背景

複数台汎用サーバで構成される分散ストレージシステムが知られている。分散ストレージシステムでは、TCP/IP等の汎用ネットワークを用いてサーバ間が接続されている。汎用ネットワークは、PCI等の内部バスに比べて低帯域・高レイテンシであるため、サーバ間のデータ転送量が極力小さくなるように制御することが好ましい。

例えば、特許文献1には、分散Erasure Codingを適用した分散ストレージシステムについて、ホストからのデータ読み出し要求に対して、ホストから要求を受けたサーバ内のデバイスからデータを読み出せるようにデータ格納先を工夫し、データ読み出しに伴うサーバ間のデータ転送が少なくなるよう構成する技術が開示されている。

一方、ストレージ高速化技術の1つに、デバイスから読み出したデータを大容量キャッシュに格納し、同一データ参照時のデバイス・アクセスを不要化して高速化する技術がある。例えば、特許文献2には、ストレージに搭載されたデバイスにキャッシュデータを格納し、大容量キャッシュを実現する技術が開示されている。

概要

分散ストレージシステムにおいて、アクセス要求を受けた場合におけるストレージ装置間ネットワーク負荷を低減し、応答性を向上できるようにする。分散ストレージシステム1において、記憶デバイス113は、データ領域と、キャッシュ領域とを含み、ノードは、LUのデータがデータ領域に格納されていない未格納状態で他のノードからLUの担当移譲を受けた場合、オーナーノードとなり、オーナーノードのプロセッサ110を、担当するLUに対するリード要求受け付け、対象領域のデータがオーナーノードのデータ領域とキャッシュ領域とに格納されていない場合に、対象領域のデータを、他のノードの記憶デバイスのデータに基づいて取得し、要求元に送信するとともに、キャッシュ領域に格納するように構成する。

目的

本発明は、上記事情に鑑みなされたものであり、その目的は、分散ストレージシステムにおいて、アクセス要求を受けた場合におけるストレージ装置間のネットワークの負荷を低減し、応答性を向上することのできる技術を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ストレージ装置を複数備え、複数の記憶デバイスに分散してデータを管理する分散ストレージシステムであって、前記ストレージ装置は、プロセッサ部を備え、前記記憶デバイスは、データを格納するために用いられるデータ領域と、データをキャッシュするために用いられるキャッシュ領域とを含み、前記分散ストレージシステムにおいては、データを管理する論理ユニット毎に前記論理ユニットに対するアクセス担当するストレージ装置である担当ストレージ装置が設定されており、前記ストレージ装置は、論理ユニットのデータが自身がアクセス可能な前記記憶デバイスのデータ領域に格納されていない状態である未格納状態で、他のストレージ装置から前記論理ユニットの担当の移譲を受けた場合、前記担当ストレージ装置となり、前記担当ストレージ装置のプロセッサ部は、自身が担当する論理ユニットに対するリード要求受け付け、前記未格納状態の前記論理ユニットの前記リード要求の対象とする対象領域のデータを、他のストレージ装置の前記記憶デバイスのデータに基づいて取得し、前記取得した前記論理ユニットの前記対象領域のデータを前記リード要求の要求元に送信するとともに、前記取得した前記論理ユニットの前記対象領域のデータを自身がアクセス可能な前記記憶デバイスの前記キャッシュ領域に格納する分散ストレージシステム。

請求項2

前記論理ユニットのデータは、EC(ErasureCoding)を構成する複数のストレージ装置により冗長化して管理されており、前記担当ストレージ装置は、前記ECを構成するストレージ装置に障害が発生したために、障害が発生したストレージ装置である障害ストレージ装置が担当していた論理ユニットを新たに担当するように設定されたストレージ装置であり、前記担当ストレージ装置の前記プロセッサ部は、新たに担当する論理ユニットに対するリード要求を受け付け、前記リード要求の対象となる前記論理ユニットの対象領域のデータが前記障害ストレージ装置の前記記憶デバイスのデータ領域に格納されていたものであって、前記担当ストレージ装置がアクセス可能な前記記憶デバイスの前記データ領域及び前記キャッシュ領域に格納されていない場合に、前記ECを構成する障害ストレージ装置以外の複数のストレージ装置から対象領域のデータを復元するためのデータを取得し、取得した前記データに基づいて、前記対象領域のデータを復元し、前記復元したデータをリード要求の要求元に送信するとともに、復元した前記対象領域のデータを前記記憶デバイスのキャッシュ領域に格納する請求項1に記載の分散ストレージシステム。

請求項3

前記担当ストレージ装置の前記プロセッサ部は、新たに担当する論理ユニットに対するライト要求を受け付け、前記ライト要求に対応する対象領域にライトするデータを前記キャッシュ領域に格納する請求項2に記載の分散ストレージシステム。

請求項4

前記障害ストレージ装置をリプレースするためのストレージ装置であるリプレースストレージ装置が備えられた後において、前記リプレースストレージ装置の前記プロセッサ部は、前記ECを構成する障害ストレージ装置以外の複数のストレージ装置から前記論理ユニットの一部の領域のデータを復元するためのデータを取得し、前記データに基づいて、前記論理ユニットの一部の領域のデータを復元して、前記記憶デバイスのキャッシュ領域に格納し、前記ECを構成する障害ストレージ装置以外の複数のストレージ装置から前記論理ユニットの領域のデータを復元するためのデータを取得し、前記データに基づいて、前記論理ユニットの全ての領域のデータを復元して、前記記憶デバイスのデータ領域に格納し、前記論理ユニットに対応するキャッシュ領域のデータを破棄する請求項2に記載の分散ストレージステム

請求項5

前記担当ストレージ装置の前記プロセッサ部は、前記ECを構成する障害ストレージ装置以外の複数のストレージ装置から前記論理ユニットの全ての領域のデータを復元するために必要なパリティ及びデータを取得し、前記パリティ及び前記データに基づいて、前記論理ユニットの全ての領域のデータを復元して、前記記憶デバイスのデータ領域に格納し、前記論理ユニットに対応するキャッシュ領域のデータを破棄する請求項2に記載の分散ストレージステム。

請求項6

移譲元のストレージ装置から論理ユニットの担当が移譲された移譲先のストレージ装置のプロセッサ部は、移譲対象の前記論理ユニットについて、前記移譲元のストレージ装置から前記移譲先のストレージ装置がアクセス可能な記憶デバイスへの論理ユニットのデータのマイグレート中において、マイグレートしている前記論理ユニットを対象とし、前記論理ユニットのマイグレートが完了していない領域に対するリード要求を受け取ると、前記リード要求の対象領域のデータが前記記憶デバイスのキャッシュ領域に格納されていない場合には、前記移譲元のストレージ装置から前記対象領域のデータを読み出して、前記読み出したデータを前記リード要求の要求元に送信するとともに、前記読み出したデータを前記移譲先のストレージ装置の記憶デバイスのキャッシュ領域に格納する請求項1に記載の分散ストレージシステム。

請求項7

移譲元のストレージ装置から論理ユニットの担当が移譲された移譲先のストレージ装置のプロセッサ部は、移譲対象の前記論理ユニットについて、前記移譲元のストレージ装置から前記移譲先のストレージ装置の記憶デバイスへの論理ユニットのデータのマイグレート中において、マイグレートしている前記論理ユニットを対象とし、前記論理ユニットのマイグレートが完了していない領域に対するライト要求を受け取ると、前記ライト要求のライト対象のデータを前記移譲先のストレージ装置のデータ領域に格納させるとともに、前記ライト対象のデータを前記移譲先のストレージ装置の記憶デバイスのキャッシュ領域に格納する請求項1に記載の分散ストレージシステム。

請求項8

論理ユニットの担当を移譲する移譲元のストレージ装置のプロセッサ部は、前記論理ユニットの担当を移譲する移譲先のストレージ装置を選択し、前記移譲先のストレージ装置に対して、移譲対象の前記論理ユニットにおけるアクセス頻度の高い一部の領域のデータを、前記移譲先のストレージ装置に送信し、前記移譲先のストレージ装置のプロセッサ部は、前記移譲元のストレージ装置から送信された移譲対象の論理ユニットにおけるアクセス頻度の高い一部の領域のデータを、前記移譲先のストレージ装置の前記記憶デバイスのキャッシュ領域に格納する請求項1に記載の分散ストレージシステム。

請求項9

前記ストレージ装置のプロセッサ部は、記憶デバイスにおける容量使用率所定値以上の場合に、自ストレージ装置が担当する論理ユニットの一部のデータ領域のデータを他のストレージ装置の記憶デバイスのデータ領域に移動させる請求項1に記載の分散ストレージシステム。

請求項10

前記ストレージ装置のプロセッサ部は、自ストレージ装置の記憶デバイスにおける容量使用率が所定値未満の場合に、自ストレージ装置が担当する論理ユニットであって、前記他のストレージ装置の記憶デバイスのデータ領域に移動させたデータを、前記自ストレージ装置の前記記憶デバイスの前記データ領域に移動させ、前記自ストレージ装置の前記記憶デバイスの前記キャッシュ領域における、移動させた前記論理ユニットのデータに対応するデータを破棄する請求項9に記載の分散ストレージシステム。

請求項11

前記ストレージ装置のプロセッサ部は、前記キャッシュ領域に前記論理ユニットのデータを格納する際に、前記論理ユニットについてのキャッシュヒット率に基づいて、既存のキャッシュ領域のデータと入れ替えるか、新たなキャッシュ領域を確保するかを選択し、選択した結果に対応するキャッシュ領域に前記論理ユニットのデータを格納する請求項1に記載の分散ストレージシステム。

請求項12

前記ストレージ装置のプロセッサ部は、前記キャッシュ領域に前記論理ユニットのデータを格納する際に、前記記憶デバイスに前記キャッシュ領域として割り当てられる空き領域が存在しない場合に、前記記憶デバイスの前記データ領域のデータを、他の前記ストレージ装置の記憶デバイスのデータ領域に移動させて空き領域を生成し、前記空き領域を前記キャッシュ領域に割り当てる請求項1に記載の分散ストレージシステム。

請求項13

ストレージ装置を複数備え、複数の記憶デバイスに分散してデータを管理する分散ストレージシステムにおけるデータ管理方法であって、前記記憶デバイスは、データを格納するために用いられるデータ領域と、データをキャッシュするために用いられるキャッシュ領域とを含み、前記分散ストレージシステムにおいては、データを管理する論理ユニット毎に前記論理ユニットに対するアクセスを担当するストレージ装置である担当ストレージ装置が設定されており、前記ストレージ装置は、論理ユニットのデータが自身がアクセス可能な前記記憶デバイスのデータ領域に格納されていない状態である未格納状態で、他のストレージ装置から前記論理ユニットの担当の移譲を受けた場合、前記担当ストレージ装置となり、前記担当ストレージ装置は、自身が担当する論理ユニットに対するリード要求を受け付け、前記未格納状態の前記論理ユニットの前記リード要求の対象とする対象領域のデータを、他のストレージ装置の前記記憶デバイスのデータに基づいて取得し、前記取得した前記論理ユニットの前記対象領域のデータを前記リード要求の要求元に送信するとともに、前記取得した前記論理ユニットの前記対象領域のデータを自身がアクセス可能な前記記憶デバイスの前記キャッシュ領域に格納するデータ管理方法。

請求項14

ストレージ装置を複数備え、複数の記憶デバイスに分散してデータを管理する分散ストレージシステムにおける、所定の論理ユニットに対するアクセスを担当する担当ストレージ装置を構成するコンピュータに実行させるためのデータ管理プログラムであって、前記記憶デバイスは、データを格納するために用いられるデータ領域と、データをキャッシュするために用いられるキャッシュ領域とを含み、前記ストレージ装置は、前記論理ユニットのデータが前記記憶デバイスのデータ領域に格納されていない状態である未格納状態で、他のストレージ装置から前記論理ユニットの担当の移譲を受けた場合、前記担当ストレージ装置となり、前記データ管理プログラムは、前記コンピュータに、自身が担当する論理ユニットに対するリード要求を受け付け、前記未格納状態の前記論理ユニットの前記リード要求の対象とする対象領域のデータを、他のストレージ装置の前記記憶デバイスのデータに基づいて取得し、前記取得した前記論理ユニットの前記対象領域のデータを前記リード要求の要求元に送信するとともに、前記取得した前記論理ユニットの前記対象領域のデータを自身がアクセス可能な前記記憶デバイスの前記キャッシュ領域に格納する処理を実行させるデータ管理プログラム。

技術分野

0001

本発明は、分散ストレージシステムにおいてデータを管理する技術に関する。

背景技術

0002

複数台汎用サーバで構成される分散ストレージシステムが知られている。分散ストレージシステムでは、TCP/IP等の汎用ネットワークを用いてサーバ間が接続されている。汎用ネットワークは、PCI等の内部バスに比べて低帯域・高レイテンシであるため、サーバ間のデータ転送量が極力小さくなるように制御することが好ましい。

0003

例えば、特許文献1には、分散Erasure Codingを適用した分散ストレージシステムについて、ホストからのデータ読み出し要求に対して、ホストから要求を受けたサーバ内のデバイスからデータを読み出せるようにデータ格納先を工夫し、データ読み出しに伴うサーバ間のデータ転送が少なくなるよう構成する技術が開示されている。

0004

一方、ストレージ高速化技術の1つに、デバイスから読み出したデータを大容量キャッシュに格納し、同一データ参照時のデバイス・アクセスを不要化して高速化する技術がある。例えば、特許文献2には、ストレージに搭載されたデバイスにキャッシュデータを格納し、大容量キャッシュを実現する技術が開示されている。

先行技術

0005

国際公開第2016/052665号
特開平09−274544号公報

発明が解決しようとする課題

0006

サーバ障害等を考慮すると、常に、ホストから要求を受けたサーバ内のデバイスからデータを読み出す制御を実現することが難しい。例えば、前述の分散Erasure Coding技術によると、サーバ障害時に、データ復元に必要なデータを他サーバから読み出さなければならない。また、或るサーバのストレージ容量不足する場合、一部のデータを他サーバに格納し、このサーバからデータを読み出さなければならない。これらのデータ転送によってネットワークボトルネックにならないように、予め広帯域なネットワークを構築すると、システム高コストとなってしまう。

0007

また分散ストレージシステムでは、性能/容量負荷特定サーバに集中してボトルネックになるリスクがある。これを解消するには、ボトルネックとなったサーバが保持するデータを、別サーバマイグレーションする必要があり、ボトルネック解消に時間がかかる問題がある。

0008

本発明は、上記事情に鑑みなされたものであり、その目的は、分散ストレージシステムにおいて、アクセス要求を受けた場合におけるストレージ装置間のネットワークの負荷を低減し、応答性を向上することのできる技術を提供することにある。

課題を解決するための手段

0009

上記目的を達成するため、一観点に係る分散ストレージシステムは、ストレージ装置を複数備え、複数の記憶デバイスに分散してデータを管理する分散ストレージシステムであって、ストレージ装置は、プロセッサ部を備え、記憶デバイスは、データを格納するために用いられるデータ領域と、データをキャッシュするために用いられるキャッシュ領域とを含み、分散ストレージシステムにおいては、データを管理する論理ユニット毎に論理ユニットに対するアクセスを担当するストレージ装置である担当ストレージ装置が設定されており、ストレージ装置は、論理ユニットのデータが自身がアクセス可能な記憶デバイスのデータ領域に格納されていない状態である未格納状態で、他のストレージ装置から前記論理ユニットの担当の移譲を受けた場合、担当ストレージ装置となり、担当ストレージ装置のプロセッサ部は、自身が担当する論理ユニットに対するリード要求受け付け、未格納状態の論理ユニットのリード要求の対象とする対象領域のデータを、他のストレージ装置の記憶デバイスのデータに基づいて取得し、取得した論理ユニットの対象領域のデータをリード要求の要求元に送信するとともに、取得した論理ユニットの対象領域のデータを自身がアクセス可能な記憶デバイスのキャッシュ領域に格納する。

発明の効果

0010

本発明によれば、分散ストレージシステムにおいて、アクセス要求を受けた場合におけるストレージ装置間のネットワークの負荷を低減し、アクセスの応答性を向上することができる。

図面の簡単な説明

0011

図1は、実施例1に係る分散ストレージシステムの全体構成図である。
図2は、実施例1に係るメモリの構成図である。
図3は、実施例1に係る分散ストレージシステムにおけるデータの論理構成図である。
図4は、実施例1に係るノードプールの構成図である。
図5は、実施例1に係るデータページ管理テーブルの構成図である。
図6は、実施例1に係るキャッシュ管理テーブルの構成図である。
図7は、実施例1に係る性能モニタ管理テーブルの構成図である。
図8は、実施例1に係るキャッシュデータ登録処理フローチャートである。
図9は、実施例1に係るキャッシュページ確保処理のフローチャートである。
図10は、実施例1に係る分散Erasure Coding方式の概要図である。
図11は、実施例1に係るノード情報管理テーブルの構成図である。
図12は、実施例1に係るノード障害処理のフローチャートである。
図13は、実施例1に係るRead処理のフローチャートである。
図14は、実施例1に係るデータ復元処理のフローチャートである。
図15は、実施例1に係るWrite処理のフローチャートである。
図16は、実施例1に係るデータ符号化処理のフローチャートである。
図17は、実施例1に係るリビルド処理のフローチャートである。
図18は、実施例2に係るデータ再配置処理のフローチャートである。
図19は、実施例2に係るRead処理のフローチャートである。
図20は、実施例2に係るWrite処理のフローチャートである。
図21は、実施例3に係るLUマイグレーション管理テーブルの構成図である。
図22は、実施例3に係るLUマイグレーション処理のフローチャートである。
図23は、実施例3に係るRead処理のフローチャートである。
図24は、実施例3に係るWrite処理のフローチャートである。
図25は、実施例4に係るキャッシュウォーミング処理のフローチャートである。

0012

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

0013

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

0014

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

0015

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

0016

また、以下の説明では、「プログラム」を動作の主体として処理を説明する場合があるが、プログラムは、プロセッサ(例えばCPU)によって実行されることで、定められた処理を、適宜に記憶資源(例えばメモリ)及び/又は通信インターフェース装置(例えばポート)を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサを含む装置が行う処理としてもよい。また、プロセッサが行う処理の一部又は全部を行うハードウェア回路を含んでもよい。コンピュータプログラムは、プログラムソースから装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバ、又は、計算機読み取り可能な記憶メディアであっても良い。

0017

図1は、実施例1に係る分散ストレージシステムの全体構成図である。

0018

分散ストレージシステム1は、複数台のホストサーバ(以下、ホストという)102と、複数台のストレージサーバ(ストレージ装置の一例、以下、ノードという)103と、管理サーバ104とを備える。各ホスト102と、各ノード103とは、ネットワーク105を介して接続されている。各ノード103は、ネットワーク106を介して接続されている。各ノード103と管理サーバ104とは、ネットワーク107を介して接続されている。ネットワーク105、106、107は、例えば、LAN(Local Area Network)や、WAN(Wide Area Network)等であってもよく、これらのネットワーク105、106,107は、特定のトポロジや特定の通信プロトコルに依存しない。例えば、ネットワーク105、106,107を単一ネットワークとして構成してもよい。このような構成により、分散ストレージシステム1では、各ノード103に格納されているデータを各ホスト102から参照・更新でき、各ノード103間で互いにデータの送受信ができ、管理サーバ104から各ノード103を制御したり、モニタリングしたりすることができる。

0019

ホスト102は、アプリケーションを実行し、ノード103に書き込み要求ライト要求:アクセス要求の一例)を発行してノード103にデータを格納したり、ノード103に読み出し要求(リード要求:アクセス要求の一例)を発行してノード103からデータを読み出したりして、各種処理を実行する。

0020

管理サーバ104は、各ノード103の管理処理を実行する。

0021

ノード103は、各ホスト102により利用されるデータを記憶し、管理する処理を実行する。ノード103は、例えば、サーバ装置や、PC(Personal Computer)等の物理計算機により構成され、1個以上のプロセッサ110、1個以上のメモリ111、1個以上のネットワークI/F112、及び1個以上の記憶デバイス113を備える。

0022

ネットワークI/F112は、例えば、Ethernet(登録商標)に対応するNIC(Network Interface Card)やFibre Channelに対応するHost Bus Adapter(HBA)などのネットワークインターフェースである。ネットワークI/F112は、ネットワーク105,106,107を介して他の装置(ホスト102、他のノード103、管理サーバ104)との通信仲介する。

0023

プロセッサ110は、メモリ111及び/又は記憶デバイス113に格納されているプログラムに従って各種処理を実行する。

0024

メモリ111は、例えば、RAMであり、プロセッサ110で実行されるプログラムや、必要な情報を記憶する。メモリ111は、揮発メモリ又は不揮発メモリのいずれでもよい。

0025

記憶デバイス113は、例えばHDD(Hard Disk Dreive)やSSD(Solid State Drive)等であり、プロセッサ110で実行されるプログラムや、プロセッサ110に利用されるデータや、ホスト102で利用されるデータ等を記憶する。

0026

なお、ノード103におけるプロセッサ110、メモリ111、ネットワークI/F112、記憶デバイス113を、サーバ仮想化技術を用いた仮想的なハードウェアとして構成してもよい。すなわち、ノード103をVirtual Machine(VM)で構成してもよい。

0027

分散ストレージシステム1において、ホスト102とノード103とを同一の物理計算機上に配置するようにしてもよい。この場合には、例えば、同一の物理計算機において、ホスト102とノード103とをそれぞれVM上で動作させるようにすればよい。

0028

図2は、実施例1に係るメモリの構成図である。

0029

メモリ111は、データページ管理テーブル401と、キャッシュ管理テーブル501と、性能モニタ管理テーブル601と、ノード情報管理テーブル901と、キャッシュデータ登録プログラム700と、ノード障害処理プログラム1000と、Readプログラム1100と、復号化プログラム1109と、Writeプログラム1200と、符号化プログラム1205と、リビルドプログラム1300とを格納する。これらテーブルの詳細や、各プログラムを実行することにより実現される処理については後述する。

0030

図3は、実施例1に係る分散ストレージシステムにおけるデータの論理構成図である。

0031

各ノード103には、複数個のLogical Unit(LU:論理ユニット)201を定義することができる。ホスト102は、このLU201に対してブロックI/O(ブロックを単位とするI/O)を行うことができる。ノード103は、ホスト102からのブロックI/Oを受領できる。各LU201は、いずれのノード103に接続されたホスト102からでも参照・更新することが可能である。

0032

一般的に、複数のノード103からLU201の参照・更新を行う場合、データの一貫性維持のため、ノード103間で何かしらの排他手続きが必要となる。本実施例では、LU201ごとにI/O処理を担当するノード(オーナーノード:担当ストレージ装置の一例)を事前に定義し、ホスト102からI/O要求を受領したノード103が、I/O要求に指定されているI/O対象のLU201のオーナーノードへI/O処理要求転送し、オーナーノードのみがI/O対象のLUのI/O処理を行うことでデータの一貫性を維持するようにしている。図3に示す例では、LU#1〜#2のオーナーノードはノード#1であり、LU#3〜#4のオーナーノードはノード#2である。ノード#1とノード#2とは両者ともLU#1〜#4のブロックI/Oを受領可能である。

0033

なお、分散ストレージシステム1におけるデータの排他手続きは、上記に限られず、例えば、LU201ごとにノード103間のロック機構を設け、I/Oを受領したノードがI/O対象のLU201のロックを取得した上でI/O処理を行うようにしてもよい。また、本実施例では、LU201単位にオーナーノードを定義しているが、本発明はこれに限られず、各LU201の部分領域221ごとにオーナーノードを事前定義するようにしてもよい。

0034

また、本実施例では、ブロックI/Oを処理可能な分散ストレージシステム1としているが、ファイルオブジェクト等の非ブロックI/Oを処理可能な分散ストレージシステムとしてもよい。この場合、例えば、ファイルI/OやオブジェクトI/OをブロックI/Oに変換するプログラムを用意することで、本実施例と同等の効果を得ることができる。

0035

各ノード103内の各記憶デバイス113は、一般的なThin Provisioning技術によって固定サイズの領域(以下、ページと呼ぶ)222に分割され、ノード103ごとにプール(以下、ノードプール呼ぶ)202として管理されている。Thin Provisioning技術によると、ホスト102からの書き込み要求(ライト要求)に応じて、要求があった各LU201の部分領域221にページ222を動的に関連付け、関連付けたページ222にライト対象のデータを書き込む。

0036

各LU201に関連付けるページ222は、基本的には、LU201のオーナーノード103のノードプール202から取得する。しかしながら、このノードプール202に空きページが存在しない場合など、必要に応じて、別のノード103のノードプール202のページ222が関連付けられることがある。言い換えると、各LU201に対して複数ノードプール202のページ222が関連付けられることがある。さらに、LU201に既に関連付けされたページ222について、別のノードプール202のページ222へと関連付けるページを変更することが可能である。具体的には、変更先のノードプール202から新規にページ222を取得し、このページ222に関連付け済みページのデータをコピーし、LUに対して関連付け済みページをコピー先のページ222に変更することで容易に実現可能である。

0037

図4は、実施例1に係るノードプールの構成図である。

0038

ノードプール202が管理する領域は、永続的にデータを格納しておくためのデータ格納用のページ(データページ:データ領域の一部)301、キャッシュ格納用のページ(キャッシュページ:キャッシュ領域の一部)302、データ未格納の空きページ303の3種類に分類して管理される。ホスト102から書き込まれたデータの全ては、最終的にいずれかのデータページ301に格納される。一方で、I/O性能の向上を目的とし、一部のデータについては、キャッシュデータとしてキャッシュページ302に格納される。ノードプール202における、キャッシュページ302により構成されるキャッシュ領域と、データページ301により構成されるデータ領域との容量のバランスは、適宜変更することが可能である。キャッシュ領域とデータ領域との容量の変更方法については後述する。

0039

図5は、実施例1に係るデータページ管理テーブルの構成図である。

0040

データページ管理テーブル401は、ノード103ごとに保持されるテーブルであり、自身がオーナーノードとなる各LU(すなわち、自身が担当するLU)の各部分領域221とデータページ301との関連付け情報を管理するテーブルである。データページ管理テーブル401は、各LUの部分領域ごとに対応するエントリを格納する。データページ管理テーブル401のエントリは、LU番号(LU#)411と、部分領域先頭アドレス412と、ノード番号(ノード#)413と、デバイス番号(デバイス#)414と、デバイス内先頭アドレス415とのフィールドを含む。

0041

LU番号411には、エントリに対応するLUの番号が格納される。部分領域先頭アドレス412には、エントリに対応する部分領域の先頭アドレスが格納される。ノード番号413には、エントリに対応する部分領域に関連付けるデータページが格納されているノード103の番号が格納される。デバイス番号414には、エントリに対応する部分領域に関連付けるデータページが格納されている記憶デバイス113の番号が格納される。デバイス内先頭アドレス415には、エントリに対応する部分領域に関連付けるデータページが格納される記憶デバイス113内の先頭アドレスが格納される。なお、エントリに対応するLUの部分領域について、データページが関連付けられていない場合、すなわち、対応する部分領域にデータが格納されていない場合には、ノード番号413、デバイス番号414、及びデバイス内先頭アドレス415には、情報が格納されていない状態となっている。

0042

図6は、実施例1に係るキャッシュ管理テーブルの構成図である。

0043

キャッシュ管理テーブル501は、ノード103ごとに保持されるテーブルであり、自身がオーナーノードである各LUの各部分領域と、キャッシュデータの格納先との関連付け情報を管理するテーブルである。本実施例においては、キャッシュデータは、キャッシュページ302よりも小さな固定サイズで管理される。すなわち、キャッシュページ302ごとに複数個のキャッシュデータが格納される。また、データページ301と異なり、キャッシュページ302は自身のノードプール202からのみ取得される。なお、本実施例においては、キャッシュデータを記憶デバイス113のみに格納するようにしているが、キャッシュデータの一部をメモリ111に格納してもよい。

0044

キャッシュ管理テーブル501は、各LUの部分領域ごとに対応するエントリを格納する。キャッシュ管理テーブル501のエントリは、LU番号511と、部分領域先頭アドレス512と、デバイス番号513と、デバイス内先頭アドレス514と、キャッシュページ内オフセット515と、最終アクセス時刻516とのフィールドを含む。

0045

LU番号511には、エントリに対応するLUの番号が格納される。部分領域先頭アドレス512には、エントリに対応する部分領域の先頭アドレスが格納される。デバイス番号513には、エントリに対応する部分領域に関連付けるキャッシュページが格納されている記憶デバイス113の番号が格納される。デバイス内先頭アドレス514には、エントリに対応する部分領域に関連付けるキャッシュページの記憶デバイス113内の先頭アドレスが格納される。キャッシュページ内オフセット515には、エントリに対応する部分領域が格納されているキャッシュページ内のオフセットが格納されている。最終アクセス時刻516には、エントリに対応する部分領域に対する最終アクセス時刻の情報が格納される。図6の例では、最終アクセス時刻の情報としては、所定の時点からのタイムカウントとしているが、最終アクセス時刻の情報としては、年、月、日、時、分、秒等の情報としてもよい。ここで、キャッシュデータを管理する場合、新規のキャッシュデータを登録する時にリプレースするデータを決定するためのキャッシュリプレースアルゴリズムが必要である。本実施例では、このアルゴリズムにLeast Recent Use(LRU)を用いることを想定し、エントリに最終アクセス時刻516のフィールドを備えるようにしている。なお、キャッシュリプレースアルゴリズムに代えて、他のアルゴリズムを利用してもよい。

0046

図7は、実施例1に係る性能モニタ管理テーブルの構成図である。

0047

性能モニタ管理テーブル601は、ノード103ごとに保持されるテーブルであり、自身がオーナーノードである各LUの各部分領域ごとの、ホスト102からのI/O状況を管理するテーブルである。性能モニタ管理テーブル601は、各LUの部分領域毎のエントリを格納する。性能モニタ部分テーブル601のエントリは、LU番号611と、部分領域先頭アドレス612と、IOPS613と、キャッシュヒット率614とのフィールドを含む。

0048

LU番号611には、エントリに対応するLUの番号が格納される。部分領域先頭アドレス612には、エントリに対応する部分領域の先頭アドレスが格納される。IOPS613には、エントリに対応する部分領域に対するIOPS(I/O per Second)が格納される。キャッシュヒット率614には、エントリに対応する部分領域に対するキャッシュヒット率が格納される。IOPSや、キャッシュヒット率の取得方法については公知であるので詳細な記載は省略する。本実施形態では、エントリにIOPSやキャッシュヒット率を格納するようにしているが、本発明はこれに限られず、エントリに対応する部分領域についてのI/O状況を示す情報であれば、他の情報を格納するようにしてもよい。

0049

次に、キャッシュデータ登録処理について説明する。

0050

図8は、実施例1に係るキャッシュデータ登録処理のフローチャートである。

0051

キャッシュデータ登録処理は、ノード103のプロセッサ110がキャッシュデータ登録プログラム700を実行することにより実現され、指定されたLUの部分領域のデータをキャッシュデータとして管理されるように登録する処理である。キャッシュデータ登録処理は、例えば、リード要求又はライト要求が対象とするデータをキャッシュデータとして登録する要求があった場合に、実行される。

0052

キャッシュデータ登録プログラム700(厳密には、キャッシュデータ登録プログラム700を実行するプロセッサ110)は、指定されたLUの部分領域に既にキャッシュデータが登録されているか否かを判定する(S701)。ここで、LUの部分領域にキャッシュデータが登録されているか否かについては、キャッシュ管理テーブル501を参照して、指定されたLUの部分領域に対応するエントリにおいて、デバイス番号513、デバイス内先頭アドレス514、及びキャッシュページ内オフセット515に値が設定されているか否かにより特定することができる。

0053

この結果、指定されたLUの部分領域に既にキャッシュデータが登録されている場合(S701:Yes)には、キャッシュデータ登録プログラム700は、登録されているキャッシュデータを、指定されているキャッシュ対象のデータ(キャッシュ対象データ)に書き換え(S702)、処理を終了する。

0054

一方、指定されたLUの部分領域にキャッシュデータが登録されていない場合(S701:No)には、キャッシュデータ登録プログラム700は、既存のキャッシュページにキャッシュ対象データが格納可能な空き領域が存在するか否かを判定する(S703)。ここで、例えば、キャッシュページの空き領域を管理するテーブルを予め用意しておき、このテーブルを参照して、キャッシュページに空き領域が存在するか否かを判定するようにしてもよい。

0055

この結果、既存のキャッシュページにキャッシュ対象データが格納可能な空き領域が存在する場合(S703:Yes)には、キャッシュデータ登録プログラム700は、キャッシュ対象データをこの空き領域に書き込み、キャッシュ管理テーブル501の指定されたLUの部分領域に対応するエントリのデバイス番号513、デバイス内先頭アドレス514、キャッシュページ内オフセット515、及び最終アクセス時刻516に対応する値を格納し(S704)、処理を終了する。

0056

一方、既存のキャッシュページにキャッシュ対象データが格納可能な空き領域が存在しない場合(S703:No)には、キャッシュデータ登録プログラム700は、キャッシュリプレースを行ってキャッシュページを確保するか、新たなキャッシュページを取得して確保するかのいずれを実行するかを決定する(S705)。ここで、キャッシュリプレースを行ってキャッシュページを確保するか、新たなキャッシュページを取得して確保するかのいずれを実行するかについては、性能モニタ管理テーブル601の指定されたLUのエントリのキャッシュヒット率614の値などに基づいて判断してもよい。この場合、キャッシュヒット率が所定の値より小さい場合、キャッシュデータを増やしてもキャッシュヒット率が向上する見込みが小さいと考えられるため、キャッシュページをリプレースしてキャッシュページを確保すると決定してもよい。一方で、キャッシュヒット率が所定の値より大きい場合、キャッシュデータを増やすことで、キャッシュヒット率が高まる可能性があるため、新たなキャッシュページを取得して確保すると決定してもよい。

0057

キャッシュリプレースを行うことを選択したか否かを判定し(S706)、キャッシュリプレースを行うことを選択した場合(S706:Yes)には、キャッシュデータ登録プログラム700は、キャッシュリプレースを実行する(S707)。具体的には、キャッシュデータ登録プログラム700は、キャッシュ管理テーブル501上の最終アクセス時刻516の時刻最古である部分領域についての関連付け情報(エントリのデバイス番号513、デバイス内先頭アドレス514、及びキャッシュページ内オフセット515)を解除し、この関連付け情報が示す領域(キャッシュページ)のデータを、キャッシュ対象データに書き換え、この関連付け情報を、キャッシュ管理テーブル501の指定されたLUの部分領域に対応するエントリに格納する。

0058

一方、キャッシュリプレースを行うことを選択していない場合、すなわち、新たにキャッシュページを確保することを選択した場合(S706:No)には、キャッシュページ確保処理(図9参照)を実行することにより、新しいキャッシュページを確保し(S708)、このキャッシュページの空き領域にキャッシュ対象データを書き込み、キャッシュ管理テーブル501の指定されたLUの部分領域に対応するエントリに対応する関連付け情報を格納して(S709)、処理を終了する。

0059

次に、キャッシュページ確保処理(図8のS708)について詳細に説明する。

0060

図9は、実施例1に係るキャッシュページ確保処理のフローチャートである。

0061

キャッシュページ確保処理では、キャッシュデータ登録プログラム700は、自身(自身が属するノード103)のノードプール202に空きページが存在するか否かを判定し(S710)、空きページが存在する場合(S710:Yes)は、空きページをキャッシュページとして確保し(S711)、処理を戻す。

0062

一方、空きページが存在しない場合(S710:No)には、キャッシュデータ登録プログラム700は、データページをキャッシュページに変換する処理を実行する(S712〜S715)。具体的には、キャッシュデータ登録プログラム700は、性能モニタ管理テーブル601を参照して、自ノード103のI/O頻度(IOPS)が低いページ(ページA)を選択し(S712)、ノードプール202に空きページが存在する他のノード103の1つを選択して、そのノード103のノードプール202の空きページからデータページ(ページB)を確保し(S713)、ページAからデータを読み出して、確保したページBにコピーする(S714)。次いで、キャッシュデータ登録プログラム700は、ページAをキャッシュページとして確保し(S715)、処理を戻す。

0063

これにより、キャッシュ対象データを格納するキャッシュページを適切に確保することができる。例えば、ノード103に空きページがない場合には、データページのデータを他のノード103に移動させて、キャッシュページの容量を増加させることができる。このため、キャッシュによるアクセス性能の向上を図ることができる。

0064

次に、分散ストレージシステム1における分散Erasure Coding(以下、分散EC)方式について説明する。

0065

図10は、実施例1に係る分散Erasure Coding方式の概要図である。

0066

分散ECとは、Erasure Coding技術を使って複数ノード103間でデータを保護する技術である。分散ECによると、別々のノード103に格納されているデータからパリティを作成し、作成されたパリティを、パリティ作成に使ったデータが格納されていないノード103に格納することで、ノード障害時のデータ喪失を防ぐことが可能となる。例えば、或るノード103に障害が発生して、このノード103に格納されたデータが参照不可となった場合、このデータに対応するパリティと、このパリティの作成に使ったデータとを各ノード103から読み出し、これらのパリティ及びデータから参照不可となったデータを復元することができる。例えば、図10の例では、ノード#1のデータD1、ノード#2のデータD2、ノード#3のデータD3から、パリティP1を生成し、このパリティP1をノード#4に格納しておくと、例えば、ノード#2に障害が発生し、ノード#2からデータD2を読み出すことができない場合でも、ノード#1からデータD1、ノード#3からデータD3、ノード#4からパリティP1を読み出し、データD1、データD3、及びパリティP1からデータD2を復元することができる。分散ECには多種多様な方式が提案されているが、本実施例では、例えば、特許文献1で開示されている方式を用いてもよい。なお、分散EC方式は、これに限られず、例えばReed−Solomon符号等を使った分散EC方式を用いてもよい。

0067

次に、ノード情報管理テーブル901について詳細に説明する。

0068

図11は、実施例1に係るノード情報管理テーブルの構成図である。

0069

ノード情報管理テーブル901は、ノード103ごとに保持されるテーブルであり、分散ストレージシステム1を構成する各ノード103の管理情報を格納するテーブルである。ノード情報管理テーブル901は、各ノードに対応するエントリを格納する。ノード情報管理テーブル901のエントリは、ノード番号911と、生死状況912と、オーナーノードLU番号913と、新オーナーノードLU番号914と、ECノード組合せ915とのフィールドを含む。

0070

ノード番号911には、エントリに対応するノード103の番号が格納される。生死状況912には、エントリに対応するノード103の生死状況が格納される。生死情報としては、ノード103に障害が発生してデータの参照不可である状態であることを示す「Failure」と、ノード103に障害が発生していないことを示す「Active」とがある。オーナーノードLU番号913には、エントリに対応するノード103が担当する(エントリに対応するノード103がオーナーノードとなっている)LUの番号(識別子)が格納される。新オーナーノードLU番号914には、他のノードに発生した障害によって、エントリに対応するノード103が一時的に担当する(エントリに対応するノード103が新オーナーノードとなっている)LUの番号が格納される。ECノード組合せ915には、ECを構成するノードの組合せ、すなわち、データを格納するノードと、パリティを格納するノードとの組合せが格納される。本実施例においては、各ノード103に格納されているノード情報管理テーブル901は、例えば、Paxos等のプロトコルを用いて同期して管理される。なお、ノード情報管理テーブル901は、一部のノード103のみに格納されていてもよく、ノード103以外の装置(例えば、管理サーバ104等)に配置されていてもよい。

0071

次に、ノード障害処理について説明する。

0072

図12は、実施例1に係るノード障害処理のフローチャートである。

0073

ノード障害処理は、複数のノード103の中のいずれかのノード(以下、代表ノードという)103において、プロセッサ110が、例えば、定期的にノード障害処理プログラム1000を実行することにより実現される。

0074

代表ノード103(詳細には、ノード障害処理プログラム1000を実行するプロセッサ110)は、分散ストレージシステム1を構成する各ノード103の生死状況を確認する(S1001)。例えば、分散ノード103は、各ノード103との間で通信を行い、各ノード103の生死状況を確認する。

0075

代表ノード103は、障害が発生したノード(障害ノード)があるか否かを判定する(S1002)。この結果、障害ノードがない場合(S1002:No)には、代表ノード103は、処理を終了する。

0076

一方、障害ノードがある場合(S1002:Yes)には、代表ノード103は、各ノード103のノード情報管理テーブル900における障害ノードに対応するエントリの生死状況912を「Failure」に更新する(S1003)。次いで、代表ノード103は、障害ノードがオーナーノードであった各LUについて、新しいオーナーノード(新オーナーノード)を決定し、各ノードのノード情報管理テーブル901の新オーナーノードに対応するエントリの新オーナーノードLU番号914を更新し(S1004)、処理を終了する。

0077

本実施例に係る分散ストレージシステム1は、上記したテーブルおよびプログラムを用い、ノード103に障害が発生して読み出し対象のデータを喪失している場合に、データを復元し、一度復元したデータをキャッシュデータとして保持することで、このデータに対して再度アクセスが発生した場合のノード間データ転送量を削減し、ネットワークがボトルネックになることによる一時的な性能低下を防止することができるようにする。この点について、以下に詳細に説明する。

0078

次に、Read処理について説明する。

0079

図13は、実施例1に係るRead処理のフローチャートである。

0080

Read処理は、ノード103のプロセッサ110がReadプログラム1100を実行することにより実現される。なお、図13においては、便宜的に、複数のノード103においてReadプログラム1100を実行することにより実行される処理を含んだフローチャートとなっている。

0081

まず、分散ストレージシステム1を構成するノード103の中で、ホスト102から読み出し要求(Read要求)が送信されたノード(以下、受信ノードという)が、ホスト102からのデータの読み出し要求を受領する(S1101)。ここで、読み出し要求には、例えば、読み出し対象のデータのLUと、読み出し対象の部分領域の先頭アドレス、読み出し対象のデータのデータ長等が含まれている。

0082

次いで、受信ノードは、ノード情報管理テーブル901を参照し、読み出し要求の対象となるデータ(読み出し対象データ)を有するLUのオーナーノードと、そのオーナーノードの生死状況とを確認する(S1102)。この結果、オーナーノードが生存している場合(S1102:Active)、受信ノードは、オーナーノードに対して、読み出し対象データを読み出す要求(対象データ読み出し要求:ライト要求の一例)を送信する(S1103)。

0083

この対象データ読み出し要求を受領したオーナーノードは、データページ管理テーブル401を参照し、対象データ読み出し要求に含まれているLUの部分領域に対応するノード番号、デバイス番号、デバイス内先頭アドレスを特定し、特定されたノード番号及びデバイス番号に対応する記憶デバイス113の特定されたデバイス内先頭アドレスから始まる領域のデータを読み出して受信ノードに応答する(S1104)。次いで、読み出し対象データを受信した受信ノードは、読み出し要求元のホスト102に対して読み出し対象データを応答(送信)し(S1105)、処理を終了する。

0084

一方、ステップS1102において、オーナーノードが生存していない場合(S1102:Failure)、受信ノードは、ノード情報管理テーブル901を参照し、読み出し対象データを含むLUの復元処理を担当するノード(新オーナーノード)にデータ復元要求(リード要求の一例)を送信する(S1106)。データ復元要求を受領した新オーナーノードは、自身のキャッシュ管理テーブル501を参照し、復元対象データが以前に復元済であってキャッシュデータとして保持されているか否かを判定する(S1107)。キャッシュデータとして保持されている場合(S1107:Yes)、新オーナーノードは、キャッシュ管理テーブル501から、キャッシュデータが保存されているデバイス番号と、デバイス内先頭アドレスと、キャッシュページ内オフセットを特定し、特定したデバイス番号に対応する記憶デバイス113の特定したデバイス内先頭アドレス及びオフセットに対応するアドレスから始まる領域にキャッシュされている復元対象データを読み出して、受信ノードに応答する(S1108)。この結果、受信ノードでは、送信した復元対象データを用いて、ステップS1105の処理を行う。

0085

一方、ステップS1107において、キャッシュデータとして保持されていない場合(S1107:No)、新オーナーノードは、復元対象データを復元するデータ復元処理(S1109)を実行し、復元したデータを受信ノードに送信する。

0086

上記したRead処理によると、復元対象データが以前に復元済であり、キャッシュデータとして保持されている場合には、復元対象データを復元するために必要な他のノードとの間のデータ転送を行うことなく、すなわち、ネットワーク106に負荷を掛けることなく、復元対象データを受信ノードに迅速に送信することができる。

0087

次に、データ復元処理(図13のS1109)について詳細に説明する。

0088

図14は、実施例1に係るデータ復元処理のフローチャートである。

0089

データ復元処理は、ノード103のプロセッサ110が復号化プログラム1109を実行することにより実現される。

0090

ノード103(本実施例では、新オーナーノード)は、ノード情報管理テーブル901を参照し、復元対象データの復元に必要なデータおよびパリティが格納されているノード番号を特定し、特定したノード番号の各ノード103に対してデータまたはパリティの読み出し要求を送信する(S1110)。読み出し要求を受領した各ノード103は、対応するデータまたはパリティを自身の記憶デバイス113から読み出して新オーナーノードに応答(送信)する(S1111)。新オーナーノードは、分散EC技術を用い、受領したデータおよびパリティから復元対象データを復元して受信ノードに応答する(S1112)。なお、このステップにおいては、復元対象データにおける、故障ノードに格納されていたデータ部分については、パリティ及び他のデータを用いてデータ部分を復元し、他のノードに格納されているデータ部分については、他のノードから取得したデータそのものとすることができる。次いで、新オーナーノードは、復元対象データをキャッシュデータとしてノードプール202に格納し、自身のキャッシュ管理テーブル501にキャッシュデータの情報を登録し(S1113)、処理を終了する。

0091

データ復元処理によると、新オーナーノードは、復元により得られた復元対象データをキャッシュデータとして保持することとなるので、以降において、復元対象データが要求された場合に、復元対象データを復元するために必要な他のノードとの間のデータ転送を行うことなく、すなわち、ネットワーク106に負荷を掛けることなく、復元対象データを受信ノードに迅速に送信することができる。

0092

次に、Write処理について説明する。

0093

図15は、実施例1に係るWrite処理のフローチャートである。

0094

Write処理は、ノード103のプロセッサ110がWriteプログラム1200を実行することにより実現される。なお、図15においては、便宜的に、複数のノード103においてWriteプログラム1200を実行することにより実行される処理を含んだフローチャートとなっている。

0095

まず、分散ストレージシステム1を構成するノード103の中で、ホスト102から書き込み要求(Write要求)及び書き込み対象データが送信されたノード(以下、受信ノードという)103が、ホスト102からのデータの書き込み要求及び書き込み対象データを受領する(S1201)。受信ノードは、ノード情報管理テーブル901を参照し、書き込み先のLUのオーナーノードと、そのオーナーノードの生死状況とを確認する(S1202)。

0096

オーナーノードが生存している場合(S1202:Active)、受信ノードは、オーナーノードに書き込み要求と書き込み対象データとを送信する(S1203)。この書き込み要求を受領したオーナーノードは、書き込み要求の対象の領域にデータページが関連付けられているかを確認し、関連付けられていなければ自身のノードプール202からデータページを取得して、取得したデータページに対応する記憶デバイス113およびアドレスに対応する領域に書き込み対象データを書き込む(S1204)。

0097

次に、オーナーノードは、書き込み対象データの冗長化を行うデータ符号化処理を実行する(S1205)。

0098

次に、オーナーノードは受信ノードに書き込み完了報告し(S1206)、オーナーノードから書き込み完了の報告を受けた受信ノードがホスト102に対して書き込み完了を報告し(S1207)、処理を終了する。なお、オーナーノードは、書き込み対象データを自身の記憶デバイス113に書き込んだ後に、書き込み完了を報告しているが、記憶デバイス113に書き込む前に不揮発メモリに記憶させる等していて、書き込み対象データについてのデータロスト心配がないのであれば、記憶デバイス113に書き込む前に書き込み完了を報告してもよい。

0099

ステップS1202において、オーナーノードが生存していない場合(S1202:Failure)、受信ノードは、新オーナーノードに書き込み要求と書き込み対象データとを送信する(S1208)。書き込み要求を受領した新オーナーノードは、自身の記憶デバイス113へ書き込みを行わずに、データ符号化処理(S1209:S1205と同様)を行う。次に、新オーナーノードは書き込み対象データをキャッシュデータとしてノードプール202に格納するとともに、キャッシュ管理テーブル501にキャッシュデータを登録する(S1211)。これにより、以降において、今回の書き込み対象データに対する読み出し要求を受信した場合には、ネットワーク106に負荷を掛けることなく、対象のデータを受信ノードに迅速に送信することができる。

0100

次に、データ符号化処理(図15のS1205、S1209)について詳細に説明する。

0101

図16は、実施例1に係るデータ符号化処理のフローチャートである。

0102

データ符号化処理は、ノード103のプロセッサ110が符号化プログラム1205を実行することにより実現される。

0103

ノード103(本実施例では、オーナーノード又は新オーナーノード)は、書き込み対象データを一次符号化して一次符号化データを生成する(S1212)。一次符号化データは、更新前のデータと、更新後のデータとから生成されるデータであって、直前のパリティとに基づいて、2次符号化データ、すなわち、新パリティを生成することのできるデータである。

0104

次に、オーナーノードは、書き込み対象データと一次符号化データとをノード情報管理テーブル901の書き込み対象データのLUのオーナーノード(新オーナーノードがあれば新オーナーノード)に対応するエントリに記載されたパリティを格納するノード番号のノード103に送信する(S1213)。これらデータを受領したノード103は、他のノードから同様に転送されたデータまたは一次符号化データを用いて二次符号化を行い(S1214)、二次符号化データ(パリティ)を自身の記憶デバイス113に書き込んでオーナーノードに書き込み完了を報告し(S1215)、処理を終了する。

0105

次に、障害が発生していたノードに格納されていたLUのデータを復元するリビルド処理について説明する。

0106

図17は、実施例1に係るリビルド処理のフローチャートである。

0107

リビルド処理は、ノード103のプロセッサ110がリビルドプログラム1300を実行することにより実現される。リビルド処理は、例えば、ユーザによる手動での指示があった場合や、障害が発生したノード103のリプレースが完了したことを検出した場合等を契機として実行される。また、リビルド処理を、上述の契機において、分散ストレージシステム1を構成する全ノード103で実行させるようにしてもよい。

0108

リビルドプログラム1300を実行するノード103は、自身が新オーナーノードであるLUがあるか否かを判定し(S1301)、自身が新オーナーノードであるLUがある場合(S1301:Yes)には、自身が新オーナーノードであるLUの中の1つを処理対象として選択し(S1302)、このLUを対象にデータ復元処理(S1109)を実行する。

0109

次いで、ノード103は、データ復元処理により復元したデータを自身の記憶デバイス113に格納し(S1303)、LUに格納された全てのデータの復元が完了した場合、ノード103は、ノード情報管理テーブル901における復元が完了したLUに関するオーナーノードを自身に更新し(S1304)、処理をステップS1301に進める。

0110

一方、ステップS1301で、自身が新オーナーノードであるLUがない場合(S1301:No)には、ノードプール202における不要になった自身のキャッシュデータ(例えば、復元したLUのキャッシュデータ)を全て破棄し、破棄したデータを格納していたキャッシュページを空きページにし(S1305)、処理を終了する。

0111

このリビルド処理においては、処理中にLUに対する読み出し要求があった場合においては、新オーナーノードにキャッシュされているキャッシュデータから読み出すことができる。このため、リビルド処理を待たずにデータを利用することができる。

0112

なお、障害ノードを他のノード(リプレースノード)にリプレースした場合においては、リビルド処理を、次のように行ってもよい。すなわち、まず、リプレースノードを新オーナーノードに設定する。具体的には、ノード情報管理テーブル901において、障害ノードがオーナーノードであるLUについて、リプレースノードを新オーナーノードとする設定を行う。次に、リプレースノードのローカルプール202に、復元するLUの一部のデータをキャッシュする。ここで、キャッシュするデータとしては、直前の新オーナーノードがキャッシュしていたデータのみであってもよく、LUの中のアクセス頻度が高いデータとしてもよい。その後、図17と同様なリビルド処理を実行する。

0113

これにより、処理中のLUに対する読み出し要求に対してキャッシュデータを用いて対応できるとともに、リビルド処理後に、リプレースノードを、障害ノードと同様な状態、すなわち、障害ノードがオーナーノードであったLUに対するオーナーノードに設定することができる。

0114

以上説明したように、本実施形態に係る分散ストレージシステム1によると、いずれかのノード103に障害が発生した場合において、障害ノードに格納されていた同一データに対して複数回の読み出し要求を行った場合に、2回目以降のデータ読み出しをデータ復元なしで読み出すことが可能となり、I/O性能の向上が見込める。なお、本実施例においては、新オーナーノードに復元データをキャッシュする例を示したが、別のノード(例えば、受信ノード)に復元データをキャッシュするようにしてもよい。

0115

次に、実施例2に係る分散ストレージシステムについて説明する。

0116

実施例2に係る分散ストレージシステムは、ノードプール202の空きページが不足して、別ノードのノードプール202に書き込みデータを格納せざるを得ない場合に、オーナーノードにこのデータのキャッシュデータを保持するようにすることで、I/O性能を向上させることができるシステムである。

0117

本実施例に係る分散ストレージシステムは、メモリ111にさらにデータ再配置プログラムを格納する。また、Readプログラム及びWriteプログラムについて、処理内容を変更している。

0118

図18は、実施例2に係るデータ再配置処理のフローチャートである。

0119

データ再配置処理は、ノード103のプロセッサ110がデータ再配置プログラムを実行することにより実現される。データ再配置処理は、例えば、定期的に、各ノード103により実行される。

0120

ノード103は、自ノードのノードプール202の空きページ数監視し、ノードプールの容量使用率が所定の閾値以上であるか否かを確認する(S1401)。この結果、容量使用率が閾値以上の場合(S1401:Yes)は、ノード103は、性能モニタ管理テーブル601を参照し、自ノードがオーナーノードであるLUの各部分領域から、アクセス頻度(IOPS)が最も小さい部分領域を選択し(S1402)、選択した部分領域を別ノード103のノードプール202のデータページに移動し(S1403)、処理を終了する。

0121

一方、容量使用率が閾値を下回る場合(S1401:No)、ノード103は、データページ管理テーブル401を参照し、自ノードがオーナーノードであるLUの部分領域の中に、他ノード103のノードプール202のデータページを参照している部分領域が存在するか否かを判定する(S1404)。この結果、他ノード103のノードプール202のデータページを参照している部分領域が存在する場合(S1404:Yes)、ノード103は、性能モニタ管理テーブル601を参照し、これら部分領域の中で、最もアクセス頻度が大きい部分領域を選択して(S1405)、選択した部分領域のデータページのデータを、自身(自身のノード103)のノードプール202のデータページに移動する(S1406)。その後、ノード103は、キャッシュ管理テーブル501を参照し、S1405で選択された部分領域に関するキャッシュデータをノードプール202から破棄し(S1407)、処理を終了する。

0122

一方、他ノードのノードプール202のデータページを参照している部分領域が存在しない場合(S1404:No)、ノード103は、処理を終了する。

0123

上記したデータ再配置処理によると、自ノードのノードプール202の容量に余裕があれば、オーナーノードであるLUの部分領域のデータを自ノードに格納するようにし、容量に余裕がなければ、他のノードに格納するようにすることができ、ノードプール202にキャッシュに利用できる容量を適切に確保することができる。

0124

次に、Read処理について説明する。

0125

図19は、実施例2に係るRead処理のフローチャートである。

0126

Read処理は、ノード103のプロセッサ110がReadプログラムを実行することにより実現される。なお、図19においては、便宜的に、複数のノード103においてReadプログラムを実行することにより実現される処理を含んだフローチャートとなっている。

0127

まず、分散ストレージシステム1を構成するノード103の中で、ホスト102から読み出し要求(Read要求)が送信されたノード(以下、受信ノードという)が、ホスト102からのデータの読み出し要求を受領する(S1501)。受信ノードは、ノード情報管理テーブル901を参照し、読み出し対象のデータ(本処理の説明において、対象データという)が含まれるLUのオーナーノードを特定し、オーナーノードに、読み出し要求を発行する(S1502)。

0128

読み出し要求を受け取ったオーナーノードは、データページ管理テーブル401を参照し、対象データが格納されているデータページが自ノード103のノードプール202のデータページであるか否かを判定する(S1503)。

0129

この結果、対象データが自ノード103のノードプール202のデータページである場合(S1503:Yes)、オーナーノードは、データページに対応するアドレスから対象データを読み出して受信ノードに応答する(S1504)。読み出した対象データを含む応答を受け取った受信ノードは、ホスト102に応答し(S1505)、処理を終了する。

0130

一方、対象データが自ノードのノードプール202のデータページでない場合(S1503:No)、オーナーノードは、キャッシュ管理テーブル601を参照し、対象データがキャッシュされているか否かを判定する(S1506)。

0131

この結果、キャッシュデータが存在する場合(S1506:Yes)、オーナーノードは、キャッシュデータを読み出して受信ノードに応答する(S1507)。

0132

一方、キャッシュデータが存在しない場合(S1506:No)、オーナーノードは、対象データを格納しているノード103に読み出し要求を発行する(S1508)。読み出し要求を受領したノード103は、対象データを読み出し、オーナーノードに応答する(S1509)。応答を受け取ったオーナーノードは、対象データを含む応答を受信ノードに行い、対象データをキャッシュデータとして自身に登録する(S1510)。このように、自身が担当するLUについてのデータが、他のノード103にある場合においては、読み出し要求があった場合に、キャッシュデータとして登録するようにするので、以降において、同じデータに対しては、他のノード103からの読み出しを行わずに済み、ネットワーク106に負荷を掛けることなく、対象のデータを受信ノードに迅速に送信することができる。

0133

次に、Write処理について説明する。

0134

図20は、実施例2に係るWrite処理のフローチャートである。

0135

Write処理は、ノード103のプロセッサ110がWriteプログラムを実行することにより実現される。なお、図20においては、便宜的に、複数のノード103においてWriteプログラムを実行することにより実行される処理を含むフローチャートとなっている。

0136

まず、分散ストレージシステム1を構成するノード103の中で、ホスト102から書き込み要求(Write要求)及び書き込み対象データが送信されたノード(以下、受信ノードという)が、ホスト102からのデータの書き込み要求及び書き込み対象データ(本処理の説明において対象データという)を受領する(S1601)。受信ノードは、ノード情報管理テーブル901を参照し、書き込み要求の対象のLUについてのオーナーノードを特定し、オーナーノードに、書き込み要求及び対象データを発行(送信)する(S1602)。

0137

書き込み要求を受け取ったオーナーノードは、データページ管理テーブル401を参照し、書き込み対象の部分領域にデータページが割当済か否かを判定する(S1603)。この結果、書き込み対象の部分領域にデータページが割当済でない場合(S1603:No)には、オーナーノードは、この部分領域に対してデータページを割り当て(S1605)、割り当てられているデータページに対して、対象データを書き込み、受信ノードに完了報告の応答する(S1606)。

0138

一方、書き込み対象の部分領域にデータページが割当済である場合(S1603:Yes)、オーナーノードは、データページが自身のノードプール202のデータページであるか否かを確認する(S1604)。この結果、データページが自身のノードプール202のデータページである場合(S1604:Yes)、オーナーノードは処理をステップS1606に進める。

0139

一方、データページが自身のノードプール202のデータページでない場合(S1604:No)、オーナーノードは、データページのあるノード103に書き込み要求を発行する(S1608)。

0140

書き込み要求を受領したノードは、対応するデータページに対象データを書き込み、オーナーノードに完了報告の応答を行う(S1609)。完了報告を受け取った、オーナーノードは、受信ノードに完了報告の応答を行い、対象データを自身のノードプール202にキャッシュし、キャッシュ管理テーブル501に対象データのキャッシュに関する情報を登録する(S1610)。

0141

S1606又はS1610における完了報告の応答を受け取った受信ノードは、ホスト102に完了報告を行う(S1607)。

0142

次に、実施例3に係る分散ストレージシステムについて説明する。

0143

実施例3に係る分散ストレージシステムでは、ノード103間でLUのマイグレーションを行う場合に、マイグレーション中に発生したこのLUのI/Oに係るデータをキャッシュすることで、I/O性能を向上させるようにする。LUのマイグレーションでは、LUのオーナーノードを変更することが可能であるが、LUのマイグレーションを開始した後に、このLUのオーナーノードを新たなノード103に切り替えるので、LUのマイグレーションが完了するまでのI/Oは、新たなノード103にLUの全領域のデータが揃っていないのでリードリモートになってしまう。これに対して、本実施例では、マイグレーションを行うLUのデータをキャッシュするようにしてので、アクセスの性能向上が見込める。例えば、複数のノード間103で負荷分散を行う場合に有効である。

0144

本実施例に係る分散ストレージシステムは、メモリ111にさらにLUマイグレーション管理テーブル1700と、LUマイグレーションプログラム1800とを格納している。また、Readプログラム及びWriteプログラムについて、処理内容を変更している。

0145

次に、LUマイグレーション管理テーブル1701について説明する。

0146

図21は、実施例3に係るLUマイグレーション管理テーブルの構成図である。

0147

LUマイグレーション管理テーブル1701は、実行中のLUマイグレーションに関する構成情報を管理するテーブルである。LUマイグレーション管理テーブル1701は、LUマイグレーションごとのエントリを格納する。LUマイグレーション管理テーブル1701のエントリは、マイグレーション元LU1711と、マイグレーション先LU1712と、マイグレーション完了アドレス1713とのフィールドを含む。

0148

マイグレーション元LU1711には、エントリに対応するマイグレーションのマイグレーション元(移動元)のLUの番号が格納される。マイグレーション先LU1712には、エントリに対応するマイグレーションのマイグレーション先(移動先)のLUの番号が格納される。マイグレーション完了アドレス1713には、マイグレーションが完了している領域のアドレスが格納される。

0149

次に、LUマイグレーション処理について説明する。

0150

図22は、実施例3に係るLUマイグレーション処理のフローチャートである。

0151

LUマイグレーション処理は、管理サーバ104による指示、又は、所定の契機により、実行される。LUマイグレーションプログラムを実行するノード103は、LUマイグレーションのマイグレーション元(移動元)のLU(移動元LU)に関するデータページ管理テーブル401の格納情報をマイグレーション先(移動先)のノード(移動先ノード:移譲先ノード)にコピーし(S1801)、ノード情報管理テーブル901のマイグレーション元LUのオーナーノードを移譲元ノードから移動先ノードに変更する(S1802)。

0152

次いで、ノード103は、LUに関連付けられている、マイグレーション完了アドレス(マイグレーションポインタ)の次のアドレスのデータページを選択し(S1803)、移動元ノードのノードプール202の選択されたデータページのデータを、移動先ノードのノードプール202のデータページにコピーする(S1804)。次いで、ノード103は、マイグレーション完了アドレス1713を、コピーを行ったデータページのアドレスに更新する(S1805)。

0153

次いで、ノード103は、マイグレーション対象のLUの全てのデータページの移動が終わったか否かを判定し(S1806)、LUの全てのデータページの移動が終わっていない場合(S1806:No)、処理をステップS1803に進める。

0154

一方、LUの全てのデータページの移動が終わった場合(S1806:Yes)、移動先ノードは、移動先ノードのキャッシュ管理テーブル501を参照し、このLUに関するキャッシュデータをノードプール202から破棄し(S1807)、処理を終了する。

0155

次に、Read処理について説明する。

0156

図23は、実施例3に係るRead処理のフローチャートである。

0157

Read処理は、ノード103のプロセッサ110がReadプログラムを実行することにより実現される。なお、図23においては、便宜的に、複数のノード103においてReadプログラムを実行することにより実現される処理を含むフローチャートとなっている。

0158

まず、分散ストレージシステム1を構成するノード103の中で、ホスト102から読み出し要求(Read要求)が送信されたノード(以下、受信ノードという)が、ホスト102からのデータの読み出し要求を受領する(S1901)。受信ノードは、ノード情報管理テーブル901を参照し、読み出し対象のデータ(本処理の説明において、対象データという)が含まれるLUのオーナーノードを特定し、オーナーノードに、読み出し要求を発行する(S1902)。

0159

読み出し要求を受け取ったオーナーノードは、LUマイグレーション管理テーブル1800を参照し、対象データを含むLUがマイグレーション中か否か、及び対象データが、マイグレーションが未完了の領域のデータであるか否かを判定する(S1903)。

0160

この結果、対象データを含むLUがマイグレーション中ではない場合、又は、マイグレーション中ではあるが対象データが、マイグレーションが済んでいる領域のデータである場合(S1903:No)、オーナーノードは、データページに対応するアドレスから対象データを読み出して受信ノードに応答する(S1904)。読み出した対象データを含む応答を受け取った受信ノードは、ホスト102に応答し(S1905)、処理を終了する。

0161

一方、対象データを含むLUがマイグレーション中であって、且つ対象データが、マイグレーションが未完了の領域のデータである場合(S1903:Yes)、オーナーノードは、キャッシュ管理テーブル601を参照し、対象データがキャッシュされているか否かを判定する(S1906)。

0162

この結果、キャッシュデータが存在する場合(S1906:Yes)、オーナーノードは、キャッシュデータを読み出して受信ノードに応答する(S1907)。

0163

一方、キャッシュデータが存在しない場合(S1906:No)、オーナーノードは、移動元ノードに読み出し要求を発行する(S1908)。読み出し要求を受領した移動元ノード103は、対象データを読み出し、オーナーノードに応答する(S1909)。応答を受け取ったオーナーノードは、対象データを含む応答を受信ノードに行い、対象データをキャッシュデータとして自身に登録(ノードプール202へのキャッシュデータの格納及びキャッシュ管理テーブル501への登録)する(S1910)。

0164

このように、自身が担当するLUについてのデータについて、マイグレーションが完了していない場合においては、読み出し要求があった場合に、キャッシュデータとして登録するようにするので、以降において、同じデータに対しては、他のノード103からの読み出しを行わずに済み、ネットワーク106に負荷を掛けることなく、対象のデータを受信ノードに迅速に送信することができる。

0165

次に、Write処理について説明する。

0166

図24は、実施例3に係るWrite処理のフローチャートである。

0167

Write処理は、ノード103のプロセッサ110がWriteプログラムを実行することにより実現される。なお、図24においては、便宜的に、複数のノード103においてWriteプログラムを実行することにより実行される処理を含むフローチャートとなっている。

0168

まず、分散ストレージシステム1を構成するノードの中で、ホスト102から書き込み要求(Write要求)及び書き込み対象データが送信されたノード(以下、受信ノードという)が、ホスト102からのデータの書き込み要求及び書き込み対象データ(本処理の説明において対象ノードという)を受領する(S2001)。受信ノードは、ノード情報管理テーブル901を参照し、書き込み要求の対象のLUについてのオーナーノードを特定し、オーナーノードに、書き込み要求及び対象データを発行(送信)する(S2002)。

0169

書き込み要求及び対象データを受け取ったオーナーノードは、LUマイグレーション管理テーブル1701を参照し、対象データを格納するLUがマイグレーション中か否か、及び対象データが、マイグレーションが未完了の領域のデータであるか否かを判定する(S2003)。

0170

この結果、対象データを格納するLUがマイグレーション中ではない場合、又は、マイグレーション中ではあるが対象データが、マイグレーションが済んでいる領域のデータである場合(S2003:No)、オーナーノードは、自身のノードプール202のデータページに対応するアドレスの領域に、対象データを書き込んで、受信ノードに書き込み要求に対する応答を行う(S2004)。書き込み要求に対する応答を受け取った受信ノードは、ホスト102に完了報告を行い(S2005)、処理を終了する。

0171

一方、対象データを含むLUがマイグレーション中であって、且つ対象データが、マイグレーションが未完了の領域のデータである場合(S2003:Yes)、オーナーノードは、移動元ノードに書き込み要求を発行する(S2006)。書き込み要求を受領した移動元ノード103は、対象データの書き込みを行い、オーナーノードに応答する(S2007)。応答を受け取ったオーナーノードは、完了報告を受信ノードに行い、対象データをキャッシュデータとして自身に登録(ノードプール202へのキャッシュデータの格納及びキャッシュ管理テーブル501への登録)する(S2008)。

0172

このように、自身が担当するLUについてのデータについて、マイグレーションが完了していない場合においては、書き込み要求があった場合に、キャッシュデータとして登録するようにするので、以降において、同じデータに対する読み出し要求があった場合には、他のノード103からの読み出しを行わずに済み、ネットワーク106に負荷を掛けることなく、対象データを受信ノードに迅速に送信することができる。

0173

実施例4に係る分散ストレージシステムは、実施例3に係る分散ストレージシステムを拡張したものである。本実施例では、或るノード103が所有するデータ群のうち、アクセス頻度が高いデータ群を、予め別のノード103へキャッシュデータとして格納しておくことで、特定のノード103の性能負荷が高くなってデータのマイグレーションが必要になった場合に、マイグレーション開始直後であったとしても、特定のデータにアクセスが集中した場合のノード103間のデータ転送量を削減し、ネットワークがボトルネックになることによる、一時的な性能低下を防止することができる。

0174

本実施例に係る分散ストレージシステムは、メモリ111にさらにキャッシュウォーミングプログラム2100を格納している。

0175

図25は、実施例4に係るキャッシュウォーミング処理のフローチャートである。

0176

キャッシュウォーミング処理は、ノード103のプロセッサ110がキャッシュウォーミングプログラム2100を実行することにより実現される。なお、図25においては、便宜的に、複数のノード103においてキャッシュウォーミングプログラム2100を実行することにより実現される処理も含むフローチャートとなっている。キャッシュウォーミング処理は、例えば、定期的に各ノード103において実行される。

0177

まず、キャッシュウォーミングプログラム2100を実行するノード103は、自身がオーナーノードであるLUの中から1つのLU(対象LU)を選択し(S2101)、高負荷等でマイグレーションを実行する場合にこのLUのマイグレーション先とする候補ノードを選択する(S2102)。

0178

次に、ノード103は、対象LUについて性能モニタ管理テーブル601を参照し、対象LUにおけるアクセス頻度(IOPS)の上位N(Nは、任意の整数)個のデータページを選択する(S2103)。次に、ノード103は、候補ノードに、選択したデータページ群のデータを転送し、キャッシュデータとして登録するように要求する(S2104)。候補ノードは、受信したデータを自身にキャッシュデータとして登録する(S2105)。具体的には、候補ノードは、ノードプール202に受信したデータをキャッシュするとともに、このデータのキャッシュに関する情報をキャッシュ管理テーブル501に登録する。

0179

次いで、ノード103は、自身がオーナーノードである全てのLUを対象に処理が完了したか否かを判定し(S2106)、自身がオーナーノードである全てのLUを対象に処理が完了していない場合(S2106:No)には、処理をステップS2101に進める一方、自身がオーナーノードである全てのLUを対象に処理が完了した場合(S2106:Yes)には、処理を終了する。

0180

なお、本発明は、上述の実施例に限定されるものではなく、本発明の趣旨を逸脱しない範囲で、適宜変形して実施することが可能である。

0181

例えば、上記した複数の実施例の中の2以上の実施例を組み合わせてもよい。

実施例

0182

また、上記の各構成、機能等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、不揮発性半導体メモリ、HDD、SSD等の記憶デバイス、または、ICカードSDカード、DVD等の計算機読み取り可能な非一時的データ記憶媒体に格納していてもよい。

0183

1…分散ストレージシステム、102…ホスト、103…ノード、104…管理サーバ、105,106,107…ネットワーク、110…プロセッサ、111…メモリ、112…ネットワークI/F、113…記憶デバイス

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ