JP2014203329A - ストレージシステム、ノード装置及びデータ管理方法 - Google Patents

Abstract

【課題】データの可用性を保ち分断耐性を向上させつつ、運用中にデータの格納領域を個別に調整可能にする。【解決手段】本発明のストレージシステムは、１つ以上のフロントノード５００と、１つ以上のストレージノード６００とを備え、各ストレージノード６００に、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つを対応づけ、各フロントノード５００は、ユーザからのアクセス要求を受け付け、受け付けたアクセス要求に対する処理を実行する担当を前記各フロントノード間で分散させる受付処理分散手段５０１と、前記担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、前記データの格納要求または前記データの読出要求を送信するストレージノード決定手段５０２とを含む。【選択図】図３２

Description

本発明は、ユーザ操作やアプリケーションからの要求に応じてデータの格納および格納したデータの読み出しを行うストレージシステム、ノード装置及びデータ管理方法に関する。

ユーザ操作やアプリケーションからの要求に応じてデータの格納および格納したデータの読み出しを行うデータストレージシステムの多くでは、格納されるデータのサイズが定まっていないことから、使用する記憶装置において「フラグメント」、「フラグメンテーション」または「分断化」と呼ばれる現象が発生する。この現象は、小さいサイズのデータと大きいサイズのデータを同一の記憶空間に格納することを続けていくと生じる現象であって、小さいサイズのデータを格納している記憶領域がまばらに存在することで、大きなサイズのデータの記憶領域の確保の邪魔になっている現象をいう。フラグメントが発生すると、トータルでは容量があるにもかかわらず連続的な領域が確保できなくなり、必要な大きさが確保できずデータの書き込みに失敗したり、空き領域の捜索に時間を要するために性能劣化を引き起こす。

フラグメントの発生を防止または効果的に抑制する方法として、これまでもいくつか提案がなされている。例えば、事前に大きなサイズのデータ用の領域を確保しておき、大きなサイズのデータについては予め確保していた領域を使う方法が提案されている。しかし、この方法は事前にどの位の大きさの領域をどの程度確保しておくべきなかなどを予想しなければならず実際に効率よく使用するには難しいという問題があった。

ところで、データの格納にかかる処理の効率化のために、データを保存する２次記憶領域を分散化して用いるシステムがある。特許文献１には、データを保存する２次記憶領域を分散化して用いるＳＡＮ（Ｓｔｏｒａｇｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）ストレージシステムにおけるストレージ機器の管理方法が記載されている。特許文献１に記載されているストレージ機器の管理方法は、予めストレージ機器の使用状況に関する条件とアクションとを対応づけてポリシーとして設定しておく。そして、情報収集によって得られるストレージ機器の現在の使用状況がポリシー内の条件を満たすときに、対応づけられているアクションを実行する。特許文献１には、ポリシー内の条件としてフラグメンテーションに関する条件を含むことが記載されている。

また、特許文献２には、分散型ファイルシステムの一例が記載されている。特許文献２に記載されているコンピュータベースシステムは、アプリケーション層からアクセスされるファイルシステムマネージャと、記憶空間へのダイレクトアクセスを管理するストレージサーバおよびストレージクライアントと、ファイルシステムマネージャとストレージサーバとの間の通信を確立する仮想化層を備えている。アプリケーションからファイルシステムへのアクセスが所望のデータを格納したネットワーク上の他のノードとの対応付けを伴うことにより、ファイルシステムマネージャが仮想化層を介して対応するストレージサーバとの通信を確立できるようにしている。なお、ファイルシステムマネージャから要求を受けたストレージサーバは、ストレージクライアントに対して要求を行う。ストレージサーバから要求を受けたストレージクライアントが実際に記憶空間にアクセスして所望のデータを返す。

特開２００２−１４８８１０号公報 特表２０１０−５０７８５１号公報

しかし、特許文献１に記載されているシステムは、ブロックデバイスを扱うＳＡＮストレージに関するものであり、そこではデータは一定のサイズに分割されたブロックに分割されて格納され、ファイルのような可変長サイズのデータを扱っていない。

ブロックデバイスレベルのアクセスを提供するＳＡＮストレージは、記憶領域をブロックと呼ぶ一定サイズの単位に分割し、ブロックに対するアクセス手段を提供する。あるブロックに納めたデータがどのブロックと関連しているかは関与しない。

一方、意味のある１つの関連したデータを指すファイルと呼ぶ概念がある。

このような意味のあるデータへのアクセスを実現するために、多くのコンピュータシステムでは、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｙｔｅｍ）内にファイルシステムと呼ぶモジュールをブロックデバイスの上位に構築し、ファイル名とデータを格納したブロック（多くの場合、複数のブロック）とを対応づけて管理している。ファイルシステムによりファイル名を識別子としたデータアクセスが提供される。

また、ファイルシステムは、データにアクセスできる人を制限するといった利便性向上のために、作成日時、変更日時、作成ユーザ、データサイズといった格納されたデータ自体ではなく、それに関わるデータ（これをメタデータと呼ぶ）も記憶し、利用している。

複数のコンピュータがネットワークを通して、共有しつつファイルにアクセスできるようにしたものを分散ファイルシステムと呼ぶ。この実現にあたっては、同時にファイルを更新できるように並列性の制御やロックなどの工夫を行う必要があるなど、一貫性、可用性、分断耐性を同時に担保しつつ実現するのは難しい問題であった。ここで、一貫性とは、全てのノードにおいて同時に同じデータが見えることをいう。また、可用性とは、ノード障害により生存ノードの機能性が損なわれないことをいう。また、分断耐性とは、システムが任意の通信障害などによるメッセージ損失に対し、継続して動作を行えることをいう。

このため、データを複数のコンピュータに分散して配置するのに、一貫性をある程度犠牲にするが、可用性と分断耐性を重視し、高速な読み書きを実現するといったような格納形態が広まりつつある。このような形態を、分散データストアやオブジェクトストレージと呼んでいる。

特許文献２に記載されている分散型ファイルシステムは、それによってフラグメントの発生を防ごうということまでは考慮されていない。例えば、特許文献２に記載されている格納先の分散化の方法は、アドミニストレーションモジュールが、論理空間の作成または変更の度に論理空間の各仮想アドレスと所定の記憶ノード上の物理アドレスとの間の対応テーブルを作成するために仮想化層を呼び出す必要があり、運用中にデータの格納領域を個別に調整することが難しいという問題がある。

上述したように、フラグメントの発生を防止またはより効果的に抑制するためにはデータのサイズに応じてデータの格納先を分けることが有効である。しかし、事前にどの位の大きさの領域をどの程度確保しておくべきなのかを予想するのが難しいため、運用中にデータの格納領域を個別に調整できることが好ましい。

そこで、本発明は、上述の問題を解決するために、データの可用性を保ち分断耐性を向上させつつ、運用中にデータの格納領域を個別に調整可能なストレージシステム、ノード装置及びデータ管理方法を提供することを目的とする。

本発明によるストレージシステムは、ユーザからのアクセス要求を最初に受け付ける１つ以上のフロントノードと、要求に応じて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う１つ以上のストレージノードとを備え、各ストレージノードは、データを格納するための記憶領域を有する２次記憶装置と、要求を受け付けて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含み、各ストレージノードは、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられており、各フロントノードは、ユーザからのアクセス要求を受け付け、受け付けたアクセス要求に対する処理を実行する担当を各フロントノード間で分散させる受付処理分散手段と、担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、データの格納要求またはデータの読出要求を送信するストレージノード決定手段とを含むことを特徴とする。

また、本発明によるノード装置は、データを格納するための記憶領域を有する２次記憶装置と、要求を受け付けて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含む１つ以上のストレージノードと通信可能に接続されているノード装置であって、ユーザからのアクセス要求を受け付け、受け付けたアクセス要求に対する処理を実行する担当を各フロントノード間で分散させる受付処理分散手段と、担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、データの格納要求またはデータの読出要求を送信するストレージノード決定手段とを備えたことを特徴とする。

また、本発明によるノード装置は、データを格納するための記憶領域を有する２次記憶装置と、要求を受け付けて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含み、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられており、当該ノードを識別するためのストレージノードＩＤとして、データを識別するためのＩＤに用いられているハッシュ空間と同じ空間範囲のハッシュ空間上にマッピングされるハッシュ値が割り当てられていることを特徴とする。

また、本発明によるデータ管理方法は、データを格納するための記憶領域を有する２次記憶装置と、要求を受け付けて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含む１つ以上のストレージノードの各々が、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられており、ユーザからのアクセス要求を最初に受け付けるノードである１つ以上のフロントノードが、ユーザからのアクセス要求を受け付けると、受け付けたアクセス要求に対する処理を実行する担当を各フロントノード間で分散させ、１つ以上のフロントノードが、担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、データの格納要求またはデータの読出要求を送信することを特徴とする。

本発明によれば、データの可用性を保ち分断耐性を向上させつつ、運用中にデータの格納領域を個別に調整可能なストレージシステム、ノード装置及びデータ管理方法を提供できる。したがって、データの格納領域を適宜調整することで、フラグメントの発生を防止またはより効果的に抑制できる。データの記憶領域は、例えば、運用中にストレージノードを追加や削除、変更することで調整できる。

第１の実施形態のストレージシステムの概略構成図である。 第１の実施形態のストレージシステムの構成例を示すブロック図である。 フロントノード２０１のより詳細な構成例を示すブロック図である。 キーＩＤテーブルのデータ構造の一例を示す説明図である。 フロントノード２０１の制御部１１の機能面における構成例を示すブロック図である。 ストレージノード２０２のより詳細な構成例を示すブロック図である。 コンテンツＩＤテーブルのデータ構造の一例を示す説明図である。 ストレージノード２０２の制御部２１の機能面における構成例を示すブロック図である。 ノードＩＤ管理サーバ２０４の動作の一例を示すフローチャートである。 ノードＩＤ管理サーバ２０４によるノード死活監視処理の処理フローの一例を示すフローチャートである。 ノードＩＤ管理サーバ２０４によるリクエスト待ち受け処理の処理フローの一例を示すフローチャートである。 ノードＩＤ管理サーバ２０４によるフロントノード登録処理の処理フローの一例を示すフローチャートである。 ノードＩＤ管理サーバ２０４によるストレージノード登録処理の処理フローの一例を示すフローチャートである。 ノードの担当分けの方法を概念的に示す説明図である。 Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇのモデル図である。 ノードＩＤ管理サーバ２０４による担当フロントノード捜索処理の処理フローの一例を示すフローチャートである。 ノードＩＤ管理サーバ２０４による担当ストレージノード捜索処理の処理フローの一例を示すフローチャートである。 フロントノード２０１の動作の一例を示すフローチャートである。 フロントノード２０１による受付フロントノード用リクエスト待ち受け処理の処理フローの一例を示すフローチャートである。 フロントノード２０１による担当フロントノード用リクエスト待ち受け処理の処理フローの一例を示すフローチャートである。 担当フロントノードとしてのフロントノード２０１によるＳＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。 担当フロントノードとしてのフロントノード２０１によるＧＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。 ストレージノード２０２の動作の一例を示すフローチャートである。 ストレージノード２０２によるリクエスト待ち受け処理の処理フローの一例を示すフローチャートである。 ストレージノード２０２によるＳＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。 ストレージノード２０２によるＧＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。 第１の実施形態のストレージシステムの立ち上げ動作の一例を示すシーケンス図である。 第１の実施形態のストレージシステムのデータ格納動作の一例を示すシーケンス図である。 第１の実施形態のストレージシステムのデータ読出動作の一例を示すシーケンス図である。 第１の実施形態のストレージシステムのフロントノード２０１の追加動作の一例を示すシーケンス図である。 第１の実施形態のストレージシステムのストレージノード２０２の追加動作の一例を示すシーケンス図である。 本発明によるストレージシステムの最小の構成例を示すブロック図である。

まず、本発明の技術コンセプトを簡単に説明する。本発明は、データを保存する２次記憶領域を分散させ、かつデータの特徴に応じて、保存先の２次記憶領域を選択する。さらに、データを格納する２次記憶領域を、分散化したノード（以下、ストレージノードという。）として実装することで、領域を追加しやすくし、利用の変化に対応しやすくする。例えば、各ストレージノードにデータ長に応じた記憶領域を用意させ、データ長に応じて格納先とするノードを使い分けることで、フラグメントの発生を抑制できる。

システム内のデータの一貫性を保ったまま、このように分散化されたストレージノードへのアクセスを可能にするために、本発明では、データをアクセスする際に物理アドレスの代わりに独自の固有のＩＤを用いるオブジェクトストレージへのアクセス方法を利用する。

より具体的には、データの格納先を特定するための固有のＩＤとして、ハッシュ関数への入力であるキーを用いる（以下、ＩＤやキーという語のみでは分かりにくい場合には、ユーザキーとも記述する）。また、このような固有のＩＤを用いることによって、ユーザ側は、このＩＤを指定してアクセスするだけで、データの実際の格納位置やアクセス手段を知らなくても実データに到達できる。また、システム内でデータの格納先をメタデータと切り離した形で管理できるので、データ領域の拡張性が容易に得られる。なお、本発明の方法であれば、ストレージノードの上位層にあたるノードがその固有のＩＤ（ユーザキー）とメタデータとを対応づけて管理しておけばよい。ストレージノード側でユーザキーに対応したデータを格納、取得できるように構成すればよく、ストレージノードのデータ格納方法をファイルシステムとは別の形態、例えば、ＤＢとすることもできる。

また、本発明では、オブジェクトストレージへのアクセス方法にさらなる応用を加え、実データのある２次記憶装置側（ストレージ側）と、ユーザからのアクセスを受け付ける側（アクセス処理側）とに層を分け、かつそれぞれの層を分散化させる。これにより、運用中であってもデータの格納領域を個別に調整できるようにする。また、データの格納領域に至るまでの経路上での最適化など、データの特徴に応じた効率的な格納処理を提供できるようにする。

さらに、前段のアクセス処理側の層を担当するノード（以下、フロントノードという。）を並列アクセス可能なように設計し、フロントノードの追加や削除で分散性の調整を行えるようにする。

以下、本発明の実施形態を図面を参照して説明する。図１は、本発明の第１の実施形態のストレージシステムの概略構成図である。図１に示すストレージシステム１０００は、大きく分けると、最初にアクセスされ、ユーザ１００３からデータの格納要求や格納したデータの読出要求を受け付けるノードであるフロントノード１０１を１つ以上含むフロントノード群１００１と、実際にデータを２次記憶装置に格納するノードであるストレージノード１０２を１つ以上含むストレージノード群１００２とを備える。

ユーザ１００３は、データやデータに結び付いたキーを使った操作を、フロントノード群１００１に含まれるいずれかのフロントノード１０１に行うことで、データを格納したり、格納したデータを読み出したりできる。ここで、ユーザ１００３とは、データの格納要求やデータの読出要求を行う外部のインスタンスの総称として用いてる。ユーザ１００３は、例えば、上位層のアプリケーションであってもよいし、ネットワークを介して接続されるユーザ端末などのコンピュータであってもよい。

各フロントノード１０１及び各ストレージノード１０２は、例えば、プログラムに従って動作するＣＰＵなどの情報処理装置と、メモリなどの主記憶装置（１次記憶装置）と、ＨＤＤなどの２次記憶装置と、ネットワークインタフェース部とを備えた計算機によって実現される。なお、フロントノード１０１は、２次記憶装置を直接実装せずに、外部の２次記憶装置を利用する形態であってもよい。

このように、本実施形態のストレージシステムは、データやデータに結び付いたキーを使った操作を行うことでデータを格納するストレージ機能を、フロントノード１０１とアクセスノード１０２の２層のレイヤに分けて、各々を分散ノードとして実装している。

ストレージノード１０２は、データの特徴に対応づけて複数用意され、各々が対応するデータの特徴に対して好適とされる記憶領域を提供可能なように各種パラメータが設定されている。

また、フロントノード１０１も複数用意され、ユーザ１００３から受け付けたアクセスを分散して処理する。より具体的には、フロントノード１０１は、ユーザ１００３からアクセスを受け付けて、受け付けたアクセス処理を担当するフロントノードを決定する機能と、担当フロントノードとしてアクセス処理の依頼を受けた場合に、データの特性に応じたストレージノードを選択し、選択したストレージノードに対してアクセスを実際に行う機能とを有することにより複数のクライアントからの並列アクセスが可能な構成としている。

以下、図２〜図３１を参照して、このようなストレージシステムの構成および動作についてより具体的に説明する。図２は、本実施形態のストレージシステムの他の構成例を示すブロック図である。図２に示すストレージシステム２０００は、フロントノード群２００１とストレージノード群２００２と、ノードＩＤ管理サーバ２０４とを備えている。また、図２では、ユーザ１００３の一例として、クライアント端末２００３が示されている。なお、図２にはフロントノード群２００１が３つのフロントノード２０１を含み、ストレージノード群２００２が３つのストレージノード２０２を含む例が示されているが、フロントノード２０１およびストレージノード２０２の数はこの限りではない。フロントノード群２００１が１つ以上のフロントノード２０１を含み、ストレージノード群２００２が１つ以上のストレージノード２０２を含んでいればよい。

各フロントノード２０１は、少なくとも他のフロントノード２０１と、１つ以上のストレージノード２０２と、ノードＩＤ管理サーバ２０４と通信可能に接続される。また、各ストレージノード２０２は、少なくとも１つ以上のフロントノード２０１と、ノードＩＤ管理サーバ２０４と通信可能に接続される。

以下、図中においてフロントノードＡと名付けられているフロントノードをフロントノード２０１Ａ、フロントノードＢと名付けられているフロントノードをフロントノード２０１Ｂ、フロントノードＣと名付けられているフロントノードをフロントノード２０１Ｃと記す場合がある。また、図中においてストレージノード１と名付けられているストレージノードをストレージノード２０２−１、ストレージノード２と名付けられているストレージノードをストレージノード２０２−２、ストレージノード３と名付けられているストレージノードをストレージノード２０２−３と記す場合がある。

フロントノード２０１の役割は、クライアント端末２００３その他ユーザ（他の端末およびアプリケーション層を含む）からのアクセスを補助することと、データのキャッシュを一定期間保持し応答性能を向上させることにある。以下では、ユーザの代表として、クライアント端末２００３から要求があった場合を例に用いて説明する。

また、それぞれのフロントノード２０１は、フロントノードＩＤと呼ぶ識別子を持つ。この値は、ノードの登録時に決定する。本実施形態では、各フロントノードが後述のノードＩＤ管理サーバ２０４に登録コマンドを発行し、戻り値としてフロントノードＩＤを受け取る例を示すが、フロントノードＩＤの取得方法はこの限りではない。例えば、管理者によって予め記憶領域に記憶されたものを起動時に読み出してもよい。また、以下に示す例では、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇと呼ばれるハッシュ法を利用してノードの担当範囲を決定する方法を用いるため、フロントノードＩＤを、後述するキーＩＤやコンテンツＩＤの空間と同一の範囲とする。なお、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇについては後述する。フロントノードＩＤは、例えば、キーＩＤおよびコンテンツＩＤの空間範囲として「ＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ−１）」と呼ばれるハッシュ関数のハッシュ空間を用いる場合、ＳＨＡ−１というハッシュ関数のハッシュ空間と同じ空間範囲である、０以上かつ２^１６０−１以下の値とすればよい。

図３は、フロントノード２０１のより詳細な構成例を示すブロック図である。図３に示すように、フロントノード２０１は、クライアント端末２００３からのアクセスを受け付けて後述する処理を実行する制御部１１と、ネットワークインタフェース部１２と、キーＩＤテーブルと呼ぶ管理テーブルの保持領域１３１およびキャッシュエリア１３２を少なくとも記憶領域に含む１次記憶装置１３と、保存用キーＩＤテーブルの保持領域１４１を少なくとも記憶領域に含む２次記憶装置１４とを有していてもよい。

なお、保存用キーＩＤテーブルは、１次記憶装置１３が保持するキーＩＤテーブルの退避用のテーブルである。このように、キーＩＤテーブルの内容は、更新などが行われると適時２次記憶装置１４に保存用キーＩＤテーブルとして記憶され、データが保全されることが好ましい。

また、図４は、キーＩＤテーブルのデータ構造の一例を示す説明図である。図４に示すように、キーＩＤテーブルは、キーＩＤと、キーと、メタデータと、データアドレスと、コンテンツＩＤと、有効期間とを含んでいてもよい。ここで、「キーＩＤ」には、ユーザが指定したキーを元に変換したハッシュ値を登録する。また、「キー」にはユーザから指定されたキー、より具体的にはリクエスト時に渡されたキーを登録する。また、「データアドレス」には、クライアント端末２００３から渡されたデータを記憶させた１次記憶装置１３上のキャッシュエリア１３２内のアドレスを登録する。また、「メタデータ」には、更新日時やデータなど、クライアント端末２００３から渡されたデータに関連づけるメタデータを登録する。なお、本実施形態では、メタデータに、ストレージノードの分散化において着目するデータの特徴を含ませる。なお、本例では、着目するデータの特徴として、「データ長」を含む。以下、着目するデータの特徴のことを「着目データ特徴」という場合がある。また、その着目データ特徴の具体的な内容を指して「着目データ特徴の値」という場合がある。なお、ここでいう「着目データ特徴の値」には定量的でない内容も含まれる。また、「有効期間」には、当該フロントノード２０１におけるキャッシュデータの有効期間を登録する。なお、本例では、キャッシュエリア１３２内のデータのキャッシュとしての有効時間を保持するものとする。

キャッシュエリア１３２は、１次記憶装置１３内に確保したテンポラリのデータ格納用の領域であり、ユーザとのデータの受け渡しに利用する。このエリアにあるデータの有効か無効かの判断にキーＩＤテーブルの「有効期間」エントリを使用する。

また、図５は、フロントノード２０１の制御部１１の機能面における構成例を示すブロック図である。図５に示すように、フロントノード２０１の制御部１１は、アクセス要求受付手段１１１１と担当フロントノード検索手段１１１２とを有する受付フロントノード処理部１１１と、アクセス要求受付手段１１２１と担当ストレージノード検索手段１１２２とを有する担当フロントノード処理部１１２とを含んでいてもよい。なお、これら各手段の動作については後述する。

次に、ストレージノード２０２について説明する。ストレージノード２０２の役割は、クライアント端末２００３から渡されたデータを２次記憶装置に保存することにある。本発明では、フラグメントの発生を抑制するために、各ノードの構成をより着目データ特徴に合わせたものにするのが好ましい。

以下に示す例では、格納されるデータの大きさに着目しているため、各ストレージノード２０２の２次記憶装置をあらかじめいくつかの単位に分割しておく。そして、これをフラグメント対策に利用する。すなわち、本例では、データ長ごとに専用の保存領域を設定し、使うようにする。

また、本実施形態では、フロントノード２０１とストレージノード２０２との間に、格納するデータの特性に応じた通信手段を設ける。通信手段としては、例えば、ＴＣＰ／ＩＰを使うＥｔｈｅｒｎｅｔ（登録商標）やＲＤＭＡ（Ｒｅｍｏｔｅ Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）通信が使えるＩｎｆｉｎｉＢａｎｄなどが挙げられる。

データ長が小さい場合は、ＴＣＰ／ＩＰネットワーク通信でも構わないが、データ長が大きくなるとより効率的に転送を行える通信手段を用いることが好ましい。本例では、データ長ごとに格納するストレージノード２０２が分けられるので、大きなデータを格納するストレージノード２０２との経路上で通信手段や通信方法の最適化を行うことができる。例えば、ＴＣＰ／ＩＰネットワークではＭＴＵ（Ｍａｘｉｍｕｍ ｔｒａｎｓｍｉｓｓｉｏｎ Ｕｎｉｔ）長をＥｔｈｅｒｎｅｔの標準の１５００から９０００などのように大きくしたり、ＩｎｆｉｎｉＢａｎｄを使ったＲＤＭＡ通信でデータを転送するなど、通信路を変更すればデータ特性に応じた効率的なアクセス手段を提供できる。

例えば、ＭＴＵを通常時の１５００から９０００に大きくした場合、１通信パケットあたりのデータサイズが大きくなるので、同じサイズのデータをやりとりする場合に、Ｅｔｈｅｒｎｅｔのフレーム数を最大６倍削減できる。すると、通信パケットを処理していた分のＣＰＵの負荷が減少でき、他の処理に費やすことができる。

また、それぞれのストレージノード２０２は、ストレージノードＩＤと呼ぶ識別子を持つ。この値は、フロントノード２０１同様、ノード登録時に決定する。本実施形態では、各ストレージノードが後述のノードＩＤ管理サーバ２０４に登録コマンドを発行し、戻り値としてストレージノードＩＤを受け取る例を示すが、ストレージノードＩＤの取得方法はこの限りではない。例えば、管理者によって予め記憶領域に記憶されたものを起動時に読み出してもよい。また、以下に示す例では、後述するＣｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇと呼ばれるハッシュ法を利用してノードの担当範囲を決定する方法を用いるため、ストレージノードＩＤも、キーＩＤやコンテンツＩＤの空間と同一の範囲としている。

図６は、ストレージノード２０２のより詳細な構成例を示すブロック図である。図６に示すように、ストレージノード２０２は、フロントノード２０１からのアクセスを受け付けて後述する処理を実行する制御部２１と、ネットワークインタフェース部２２と、コンテンツＩＤテーブルと呼ぶ管理テーブルの保持領域２３１およびワークエリア２３２を少なくとも記憶領域に含む１次記憶装置２３と、保存用コンテンツＩＤテーブルの保持領域２４１とデータ格納領域２４２とを少なくとも記憶領域に含む２次記憶装置２４とを有していてもよい。

なお、２次記憶装置上にある保持領域２４１に保持される保存用コンテンツＩＤテーブルは、１次記憶装置２３が保持するコンテンツＩＤテーブルの退避用のテーブルである。このように、コンテンツＩＤテーブルの内容は、更新などが行われると適時２次記憶装置２４に保存用コンテンツＩＤテーブルとして記憶し、データを保全することが好ましい。また、データ格納領域２４２は、実データを保存するための領域である。本実施形態では、各ストレージノード２０２のデータ格納領域２４２のセグメントサイズ（クラスタサイズ）を、保存するデータ長に応じて設定する。例えば、図１におけるストレージノード２０２−１ではクラスタサイズを２５６ＭＢとし、ストレージノード２０２−２ではクラスタサイズを１２８ＭＢとし、ストレージノード２０２−３ではクラスタサイズを６４ＭＢとする、といった設定を行う。なお、ストレージノードをいくつかのグループに分け、グループごとにクラスタサイズを設定することも可能である。すなわち、同じクラスタサイズのストレージノードが複数あってもよい。

また、通信などデータの受け渡しにメモリが必要な際は、ワークエリア２３２を利用すればよい。通常のＯＳでは、汎用的にメモリの割り当てが可能なため、ワークエリア２３２を特に意識して割り当てなくても実現可能である。

また、図７は、コンテンツＩＤテーブルのデータ構造の一例を示す説明図である。図７に示すように、コンテンツＩＤテーブルは、コンテンツＩＤと、データアドレスと、メタデータとを含んでいてもよい。ここで、「コンテンツＩＤ」には、格納したデータから算出したハッシュ値、いわゆる「メッセージダイジェスト」を登録する。また、「メタデータ」には、データ長、更新日時などデータに関連ついたメタデータを登録する。既に説明したように、本実施形態において、当該メタデータは着目データ特徴を含む。なお、本例では、着目データ特徴として、データ長をメタデータに含む。メタデータは、例えば、データ格納時にデータとともに渡されたものを登録すればよい。なお、当該ストレージノードで必要とされるデータを付加したものを、当該ストレージノードにおけるデータのメタデータとして登録してもよい。また、「データアドレス」には、当該ストレージノード２０２の２次記憶装置２４に格納したデータの格納先アドレスを登録する。

あるデータを与えると対応したデータよりも小さな値を返すものをハッシュ関数と呼ぶ。また、ハッシュ関数により得た値をハッシュ値と呼ぶ。ハッシュ関数として、ＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ Ａｌｇｏｒｉｔｈｍ ５）やＳＨＡ−１と呼ばれるものが広く使われている。ハッシュ値をデータの区別をするために使用した場合に、そのハッシュ値をメッセージダイジェストと呼ぶ場合がある。

また、ＳＨＡ−１アルゴリズムは、ＮＩＳＴ（Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄｓ ａｎｄ ｔｅｃｈｎｏｌｏｇｙ：アメリカ国立標準技術研究所）によって「ＦＩＰＳ ＰＵＢ １８０−１」として公開されている。また、同様のものが、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）により、「ＲＦＣ３１７４」として公開されている。このアルゴリズムは、あるデータに対し、２の１６０乗までの数値でハッシュ値を得ることができる。すなわち、データを２の１６０乗の空間にマッピングできる。ＳＨＡ−１は、ハッシュ値がハッシュ空間上に一様に分布するという特性があるため、メッセージダイジェスト用途に広く利用されている。

本実施形態では、格納されるデータにつき、ＳＨＡ−１を用いてハッシュ値を作成し、この値をコンテンツＩＤとする。そして、このコンテンツＩＤは、そのデータを格納したストレージノード２０２においてデータアドレスと紐付けされて保持される。記憶領域から取り出す際に必要となるデータサイズは、メタデータとして同時に紐付ける。メタデータは必要に応じて種類を増やしてもよい。

また、図８は、ストレージノード２０２の制御部２１の機能面における構成例を示すブロック図である。図８に示すように、ストレージノード２０２の制御部２１は、アクセス要求受付手段２１１と、アクセス実行手段２１２とを含んでいてもよい。これら各手段の動作については後述する。

次に、ノードＩＤ管理サーバ２０４について説明する。ノードＩＤ管理サーバ２０４は、各フロントノード２０１を識別するフロントノードＩＤと、各ストレージノード２０２を識別するストレージノードＩＤを管理するためのサーバである。なお、ノードＩＤ管理サーバ２０４は、実現の簡便化のために導入したものであって、ＣｈｏｒｄなどのＰ２Ｐ（Ｐｅｅｒ ｔｏ Ｐｅｅｒ）技術を用いて各ノードが他のノードとの間の情報を交換できるモジュール等を有していれば省略することも可能である。なお、Ｃｈｏｒｄとは、分散ハッシュテーブルを複数のピアで管理するための代表的なアルゴリズムの１つである。

ノードＩＤ管理サーバ２０４は、フロントノード管理テーブルと、ストレージノード管理テーブルとを保持し、各ノードからの求めに応じてこれらテーブル内の情報またはテーブル内の情報に基づく情報を提供する。ノードＩＤ管理サーバ２０４は、例えば、プログラムに従って動作するＣＰＵなどの情報処理装置と、メモリなどの主記憶装置（１次記憶装置）と、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの２次記憶装置と、ＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）などの通信装置を制御するネットワークインタフェース部とを備えた計算機によって実現される。

フロントノード管理テーブルは、当該ストレージシステムが備えるフロントノードを管理するために用いられるテーブルである。フロントノード管理テーブルは、例えば、当該ストレージシステムが備えるフロントノード２０１について、フロントノードＩＤとＩＰアドレスとを含む情報を保持するテーブルであってもよい。なお、本例では、フロントノードと他のフロントノード間、フロントノードとストレージノード間、およびノードＩＤ管理サーバとフロントノード間、ノードＩＤ管理サーバとストレージノード間で情報をやりとりするために一般的に普及しているＴＣＰ／ＩＰネットワーク通信を用いることを想定しているが、各経路の通信手段はこの限りではない。例えば、フロントノード−ストレージノード間の通信に、ＩｎｆｉｎｉＢａｎｄを利用することも考えられる。フロントノード管理テーブルは、ＩＰアドレスに加えてまたはＩＰアドレスの代わりに、他のノードが当該フロントノードと通信するために必要な情報を含んでいてもよい。

また、ストレージノード管理テーブルは、当該ストレージシステムが備えるストレージノードを管理するために用いられるテーブルである。ストレージノード管理テーブルは、例えば、当該ストレージシステムが備えるストレージノード２０２について、ストレージノードＩＤとＩＰアドレスとを含む情報を保持するテーブルであってもよい。なお、ストレージノード管理テーブルも同様に、ＩＰアドレスに加えてまたはＩＰアドレスの代わりに、他のノードが当該ストレージノードと通信するために必要な情報を含んでいてもよい。また、管理者のノードの把握を容易にするために、当該ストレージノードが対応可能な着目データ特徴に関する情報を含んでいてもよい。

次に、本実施形態の動作について説明する。本実施形態では、システムの立ち上げ時に、最初にノードＩＤ管理サーバ２０４を立ち上げた後、各ストレージノード２０２、各フロントノード２０１の順で立ち上げることが好ましい。なお、立ち上げの順序はこの限りではない。

図９は、ノードＩＤ管理サーバ２０４の動作の一例を示すフローチャートである。図９に示す例では、ノードＩＤ管理サーバ２０４は、立ち上がるとノードＩＤ管理プログラムを実行する（ステップＳ１１）。ノードＩＤ管理サーバ２０４は、ノードＩＤ管理プログラムに従って、以下の処理を行う（ステップＳ１２〜Ｓ１３）。なお、ノードＩＤ管理サーバ２０４は、ステップＳ１２の前に、初期化処理として、フロントノード管理テーブルとストレージノード管理テーブルのクリアを行った後、前回までに使用し保存していたデータ内容があれば復帰させる。他、通信用のソケットの作成など初期化処理を行う。

ステップＳ１２では、ノードＩＤ管理サーバ２０４は、ノードＩＤ管理プログラムに従い、ノードの死亡を監視するノード死活監視プログラムをフロントノード用とストレージノード用の２つ起動する。ノードＩＤ管理サーバ２０４は、ノード死活監視プログラムを起動した後は、ノードの登録要求等のリクエストを待ち受ける（ステップＳ１３）。

また、ノードＩＤ管理サーバ２０４は、終了のシグナルを受けると、フロントノード管理テーブルとストレージノード管理テーブルの内容を２次記憶装置に保存し、別に立ち上げたノード死活監視プログラムを含めたノードＩＤ管理プログラムを終了させる（ステップＳ１４のＹｅｓ，Ｓ１５）。

図１０は、ノードＩＤ管理サーバ２０４によるノード死活監視処理の処理フローの一例を示すフローチャートである。当該処理フローは、例えば、ノード死活監視プログラムに従って実行される。ノードＩＤ管理サーバ２０４は、ノード死活監視プログラムに従って、登録されたノードが活きているか、活きていないかを監視する。フロントノードを監視するノード死活監視プログラムでは、フロントノード管理テーブルを使用する。また、ストレージノードを監視するノード死活監視プログラムでは、ストレージノード管理テーブルを使用する。両者は同様の動きを行い、応答のあるノードの情報を各管理テーブル上に維持する。

死活監視は、対象ノードにネットワーク通信を行い、応答があるか否かを確認することによって行う。もし対象ノードから応答がなければ、管理テーブル上からそのノードに関するエントリを削除する。以下、この行為をＰＩＮＧと呼ぶ。

図１０に示す例では、まず、ノードＩＤ管理サーバ２０４は、全ての対象ノードにＰＩＮＧを出した状態であるか否かを確認し、全ての対象ノードにＰＩＮＧを出した状態であれば、一定時間の休止を行う（ステップＳ１１０１のＹｅｓ，Ｓ１１０２）。なお、起動直後は、フロントノードおよびストレージノードの立ち上げを待つために、全ての対象ノードにＰＩＮＧを出した状態であるとし、一定時間の休止を行う。

一定時間が経過し休止があけると、ノードＩＤ管理サーバ２０４は、対象とする管理テーブルに、登録されたノードがあれば一つ取り出し（ステップＳ１１０３）、当該ノードに対してＰＩＮＧを実行する（ステップＳ１１０４）。具体的には、登録されたノードに対して小データを送り、応答が返ってくれば活きていると判断する（ステップＳ１１０５，Ｓ１１０１に戻る）。なお、登録されたノードが１つもなければ、再びステップＳ１１０２に戻り、再び一定時間休止する。

もし応答がなければ、登録されたノードの情報を管理テーブルから削除する（ステップＳ１１０６）。

１つのノードに対するＰＩＮＧ処理が完了すると、ノードＩＤ管理サーバ２０４は、次の選択していないノードを選択し、ＰＩＮＧ処理を実行する（ステップＳ１１０１に戻り、Ｓ１１０３に進む）。これをテーブル上の全登録ノードに対して実行し、活きているノードの情報を管理テーブル上に維持する。

そして、全ての対象ノードに対してＰＩＮＧの実行をし終えると、一定時間休止する（ステップＳ１１０２）。休止があけると上記の処理を繰り返し行う。これにより、ノードＩＤ管理サーバ２０４が起動中は、定期的にノード死活監視が動作する。

次に、ノードＩＤ管理サーバ２０４によるリクエスト待ち受け処理（図９のステップＳ１３）について説明する。図１１は、ノードＩＤ管理サーバ２０４によるリクエスト待ち受け処理の処理フローの一例を示すフローチャートである。図１１に示すように、ノードＩＤ管理サーバ２０４は、リクエスト待ちうけ状態にある時に（ステップＳ１２０１）、ネットワーク通信、もしくはその他の通信手段を介してリクエストを受け取ると、受け取ったリクエストを処理する。より具体的には、受け取ったリクエストの種類を確認して、対応する処理を行い、再びリクエスト待ちうけ状態に戻る（ステップＳ１２０２〜Ｓ１２１４、ステップＳ１２０１に戻る）。

本実施形態では、ノードＩＤ管理サーバ２０４は、ＡＤＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストと、ＡＤＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストと、ＦＩＮＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストと、ＦＩＮＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストと、ＮＥＸＴ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストと、ＮＥＸＴ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストとを受け付ける。

例えば、ノードＩＤ管理サーバ２０４は、ＡＤＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストを受け付けると、フロントノード登録処理を行う（ステップＳ１２０３のＹｅｓ，Ｓ１２０４）。

ノードＩＤ管理サーバ２０４は、ＡＤＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを受け付けると、ストレージノード登録処理を行う（ステップＳ１２０５のＹｅｓ，Ｓ１２０６）。

また、ノードＩＤ管理サーバ２０４は、ＦＩＮＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストを受け付けると、担当フロントノード捜索処理を行う（ステップＳ１２０７のＹｅｓ，Ｓ１２０８）。

また、ノードＩＤ管理サーバ２０４は、ＦＩＮＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを受け付けると、担当ストレージノード捜索処理を行う（ステップＳ１２０９のＹｅｓ，Ｓ１２１０）。

また、ノードＩＤ管理サーバ２０４は、ＮＥＸＴ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストを受け付けると、次フロントノード捜索処理を行う（ステップＳ１２１１のＹｅｓ，Ｓ１２１２）。

また、ノードＩＤ管理サーバ２０４は、ＮＥＸＴ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを受け付けると、次ストレージノード捜索処理を行う（ステップＳ１２１３のＹｅｓ，Ｓ１２１４）。

以下、ノードＩＤ管理サーバ２０４が行う各リクエスト処理について説明する。図１２は、ノードＩＤ管理サーバ２０４によるフロントノード登録処理の処理フローの一例を示すフローチャートである。ノードＩＤ管理サーバ２０４は、リクエストがＡＤＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストであった場合、フロントノード登録処理を行う。なお、当該リクエストは、各フロントノード２０１が起動時にノードＩＤ管理サーバ２０４に送信する。このリクエストでは、要求元のフロントノードからフロントノードＩＤとＩＰアドレスが渡される。

図１２に示す例では、ノードＩＤ管理サーバ２０４は、渡されたフロントノードＩＤとＩＰアドレスを、フロントノード管理テーブルに格納する（ステップＳ１３０１）。そして、正常に格納できたら成功を、できなかったら失敗を、要求元のフロントノードに返却する（ステップＳ１３０２）。ＡＤＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストを受け付けることにより、ノードＩＤ管理サーバ２０４は、当該ストレージシステムが備えるフロントノードを把握する。また別の実装方法として、リクエストの際にフロントノード２０１からノードＩＤ管理サーバ２０４へ、自身（フロントノード）のＩＰアドレスを渡し、フロントノードの登録が成功した際に、ノード管理サーバ２０４から決定したフロントノードＩＤを返却する登録方法であってもよい。

また、図１３は、ノードＩＤ管理サーバ２０４によるストレージノード登録処理の処理フローの一例を示すフローチャートである。ノードＩＤ管理サーバ２０４は、リクエストがＡＤＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストであった場合、ストレージノード登録処理を行う。なお、当該リクエストは、各ストレージノード２０２が起動時にノードＩＤ管理サーバ２０４に送信する。このリクエストでは、要求元のストレージノードからストレージノードＩＤとＩＰアドレスと、当該ストレージノードが対応している着目データ特徴に関する情報（以下、対応特徴という。）が渡される。なお、対応特徴は着目データ特徴について複数の内容や範囲を示すものであってもよい。当該ストレージノード登録処理では、ストレージノードの登録ともに担当分けを行う。

図１３に示す例では、ノードＩＤ管理サーバ２０４は、渡された対応特徴の内容から当該ストレージノードが所属するクラスを判別して、所属するクラスのストレージノード管理テーブルに、ストレージノードＩＤ、対応特徴、ＩＰアドレスを登録する（ステップＳ１４０１，Ｓ１４０２）。そして、正常に格納できたら成功を、できなかったら失敗を、要求元のフロントノードに返却する（ステップＳ１４０３）。ＡＤＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを受け付けることにより、ノードＩＤ管理サーバ２０４は、当該ストレージシステムが備えるストレージノードとそのストレージノードが対応している着目データ特徴の値等を把握する。また別の実装方法として、リクエストの際にストレージノード２０２からノードＩＤ管理サーバ２０４へ、自身（ストレージノード）のＩＰアドレスと対応特徴を渡し、ストレージノードの登録が成功した際に、ノードＩＤ管理サーバ２０４から、決定したストレージノードＩＤを返却する登録方法でもよい。

図１４は、ノードの担当分けの方法を概念的に示す説明図である。図１４に示すように、ノードＩＤ管理サーバ２０４は、例えば、ストレージノードの担当分けを、着目データ特徴（本例では、データ長）に基づいて管理空間を分類することにより行ってもよい。このような場合、ノードＩＤ管理サーバ２０４は、着目データ特徴をその内容に応じて２以上のクラスに分類したクラスごとにストレージノード管理テーブルを持つようにしてもよい。

図１５は、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇのモデル図である。図１５に示すように、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇでは、ハッシュ空間を円周上に配置する。ここで、ハッシュ関数をＳＨＡ−１とした時、ハッシュ値は０≦ｘ≦２^１６０−１になる。ある特別なハッシュ値Ａ，Ｂが存在したとき、Ｂの担当範囲をＡ＜ｘ，ｘ≦Ｂ（なお、０≦ｘ≦２^１６０−１）を満たすｘと定める。ただし、ハッシュ値Ｄ，Ａが存在したとして、Ａ＜ＤかつＤが最も大きな特別なハッシュ値でＡが最も小さな特別なハッシュ値の場合は、Ｄ＜ｘ＜２^１６０−１，０≦ｘ≦Ａの値を担当範囲とする。直感的に説明すると、図１５に示す円環上に配置されたハッシュ値を、右回りに担当していく構造である。ノードに対して特別なハッシュ値を割り当て、データを識別するＩＤにハッシュ値を割り当てると、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇのアルゴリズムを利用してデータの担当範囲を決定できる。なお、ノードが追加されたときは、加わった先の左右に位置するＡ、Ｂの範囲を分割する形で担当範囲を変更でき、右回り上に位置するノード以外の他の部分に対しては影響を与えない。また、ノードが削除されたときは、削除されたノードに対応するＩＤをＢとすると、Ｂの右隣のＣへ担当範囲が拡大するが、全体には波及せず、局所的な影響に留まる。このように、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇのアルゴリズムを利用すれば、ノード数が変化してもキャッシュが全て無効化するようなことにはならない。

なお、担当範囲の割り当てを他の特徴と合わせて行いたい場合は、他の特徴の分布を含めた多次元の管理空間を用意し、各特徴の値に応じてクラスを分類すればよい。

また、図１６は、ノードＩＤ管理サーバ２０４による担当フロントノード捜索処理の処理フローの一例を示すフローチャートである。ノードＩＤ管理サーバ２０４は、リクエストがＦＩＮＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストであった場合、担当フロントノード捜索処理を行う。このリクエストでは、要求元のフロントノードからキーＩＤが渡される。渡されるキーＩＤは、ユーザが指定したキーを元に変換したハッシュ値である。このリクエストは、各フロントノード２０１がキーＩＤを元に担当するフロントノードを割り出すのに使用される。

図１６に示す例では、ノードＩＤ管理サーバ２０４は、渡されたキーＩＤを元に、このキーＩＤを担当するフロントノード２０１を決定する（ステップＳ１５０１）。本例では、フロントノード管理テーブルからＣｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇに基づき担当フロントノード２０１を決定する。より具体的には、フロントノードＩＤがマッピングされたハッシュ空間においてキーＩＤが示すハッシュ値を担当範囲とする特別なハッシュ値（ここでは、フロントノードＩＤ）を有するフロントノードを、担当フロントノードに決定する。

担当フロントノードが見つかった場合には、ノードＩＤ管理サーバ２０４は、その担当フロントノード２０１のＩＰアドレスを返り値として、要求元のフロントノード２０１に送信する（ステップＳ１５０２）。担当ノードが見つからなかった場合には、失敗を返す。

また、図１７は、ノードＩＤ管理サーバ２０４による担当ストレージノード捜索処理の処理フローの一例を示すフローチャートである。ノードＩＤ管理サーバ２０４は、リクエストがＦＩＮＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストであった場合、担当ストレージノード捜索処理を行う。このリクエストは、担当フロントノードを割り当てられたフロントノード２０１が、割り当てられたアクセス要求（データ格納要求またはデータ読出要求）を実際に行うストレージノードの情報を得るために使用される。このリクエストでは、要求元のフロントノードからコンテンツＩＤと着目データ特徴の値が渡される。渡されるコンテンツＩＤは、データ格納要求の場合は格納対象であるデータから作成されるハッシュ値である。また、データ読出要求の場合はユーザから指定されたキーと紐づけてキーＩＤテーブルに保持されていたコンテンツＩＤであって、当該データの格納時に登録されたコンテンツＩＤである。本実施形態におけるコンテンツＩＤは、担当ストレージノードの担当を決めるハッシュ値である。また、着目データ特徴の値は、要求されたデータが有する着目データ特徴の内容（本例では、データ長）である。

図１７に示す例では、ノードＩＤ管理サーバ２０４は、まず渡された着目データ特徴の値を元に、この着目データ特徴の値が属するクラスを判別する（ステップＳ１６０１）。次いで、渡されたコンテンツＩＤを元に、当該クラスにおいて、このコンテンツＩＤを担当するストレージノード２０２を決定する（ステップＳ１６０２）。本例では、クラス毎に用意したストレージノード管理テーブルからＣｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇに基づき、担当ストレージノードを決定する。より具体的には、そのクラスに属するストレージノードのストレージノードＩＤが割り当てられているハッシュ空間においてコンテンツＩＤが示すハッシュ値を担当範囲とする特別なハッシュ値（ここでは、ストレージノードＩＤ）を有するストレージノードを、担当ストレージノードに決定する。ここで、判別したクラスを担当するストレージノードが１つもない場合は、失敗を返却する。なお、失敗を返却せずに、別のクラスから捜索するなど別の方法を行ってもよい。

担当ストレージノードが見つかった場合には、ノードＩＤ管理サーバ２０４は、その担当ストレージノード２０２のＩＰアドレスを返り値として、要求元のフロントノード２０１に送信する（ステップＳ１６０３）。担当ノードが見つからなかった場合には、失敗を返す。

また、ノードＩＤ管理サーバ２０４は、リクエストがＮＥＸＴ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストであった場合、次フロントノード捜索処理を行う。なお、当該リクエストは、各フロントノード２０１が、冗長化を行う場合に他のフロントノードの情報を得るために使用されることが考えられる。このリクエストでは、起点とするフロントノードＩＤ（例えば、自フロントノードのフロントノードＩＤ）が渡される。

次フロントノード捜索処理では、例えば、ノードＩＤ管理サーバ２０４は、渡されたフロントノードＩＤを元にフロントノード管理テーブルを検索して、このフロントノードの次のフロントノードＩＤを持つフロントノードがいるかどうかを判定する。もし存在すればそのフロントノードのＩＰアドレスを返す。もし見つからなかったら失敗を返す。次フロントノードＩＤの検索は、例えば、渡されたフロントノードＩＤに＋１した値をキーＩＤとして、そのキーＩＤの担当フロントノードを捜索することにより行ってもよい。なお、＋１した値が２^１６０−１より大きくなった場合は０とする。

また、ノードＩＤ管理サーバ２０４は、リクエストがＮＥＸＴ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストであった場合、次ストレージノード捜索処理を行う。なお、当該リクエストは、各フロントノード２０１または各ストレージノード２０２が、冗長化を行う場合に他のストレージノードの情報を得るために使用されることが考えられる。このリクエストでは、起点とするストレージノードＩＤ（例えば、自ストレージノードのストレージノードＩＤや担当ストレージノードのストレージノードＩＤなど）と着目データ特徴の値とが渡される。

次ストレージノード捜索処理では、例えば、ノードＩＤ管理サーバ２０４は、渡されたストレージノードＩＤと着目データ特徴の値とを元に、着目データ特徴のクラス毎に用意したストレージノード管理テーブルを検索して、渡された着目データ特徴の値が属するクラスを担当し、かつ渡されたストレージノードＩＤの次のストレージノードＩＤを持つストレージノードがいるかどうかを判定する。もし存在すればそのストレージノードのＩＰアドレスを返す。もし見つからなかったら失敗を返す。次ストレージノードＩＤの検索は、例えば、渡されたストレージノードＩＤに＋１した値をコンテンツＩＤとして、そのコンテンツＩＤの担当ストレージノードを捜索することにより行ってもよい。なお、＋１した値が２^１６０−１より大きくなった場合は０とする。

次に、フロントノード２０１の動作について説明する。図１８は、フロントノード２０１の動作の一例を示すフローチャートである。図１８に示す例では、フロントノード２０１は、立ち上がると、フロントノードのサービスプログラムが起動される（ステップＳ２１）。そして、フロントノード２０１は、サービスプログラムに従って以下の処理を行う（ステップＳ２２〜Ｓ２７）。なお、フロントノード２０１は、まず初期化処理として、キーＩＤテーブルなどのメモリをクリアし、過去に保存していた情報があればメモリ上へ展開し状態を復帰する。また、他のノードと情報をやりとりできるようネットワーク通信用ソケットを作成する。

必要な初期化が終わると、フロントノード２０１は、自身のノードＩＤをＩＰアドレスなどの当該フロントノード２０１に固有な情報を元にＳＨＡ−１等のアルゴリズムを用いて決定する（ステップＳ２２）。

次いで、フロントノード２０１は、決定したフロントノードＩＤと、自身のＩＰアドレスなどの情報を引数に、ノードＩＤ管理サーバ２０４に登録要求（ＡＤＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエスト）を行う（ステップＳ２３）。なお、フロントノードＩＤを決定する際にＩＰアドレスの他に、ＭＡＣアドレスなどノードが持つ固有な情報を含めてもよい。また、他にノードＩＤ管理サーバ２０４に登録しておく情報があれば追加する。ここで、もし登録が失敗した場合、エラー処理を行って終了してもよい（ステップＳ２４のＮｏ）。例えば、フロントノード２０１は、サービスプログラムを終了させて、当該フロントノード２０１ではサービスを提供しないようにする。

登録が成功した場合は、次回以降同じノードＩＤを利用できるように、登録完了したノードＩＤを２次記憶装置に記憶させる（ステップＳ２５）。そして、フロントノード２０１は、クライアント端末２００３や他のフロントノード２０１からの要求を待ち受ける状態に入る（ステップＳ２６，Ｓ２７）。本例では、まず受付フロントノード用のリクエスト待ち受け処理を実行し（ステップＳ２６）、その後で担当フロントノード用のリクエスト待ち受け処理を実行する（ステップＳ２７）。そして、この２つの待ち受け処理を終了割り込みを受信するまで繰り返す。なお、受付フロントノード用と担当フロントノード用とを区別せずに、１つのリクエスト待ち受け処理で、すべてのリクエストを待ち受けるようにしてもよい。

また、フロントノード２０１は、終了割り込みを受け付けると終了処理を実行する（ステップＳ２８，Ｓ２９）。ここでは、次回立ち上げた時に同じデータ内容で動作できるようキーＩＤテーブルを２次記憶装置に保存し、プログラムを終了する。

次に、フロントノード２０１によるリクエスト待ち受け処理（図１８のステップＳ２６，Ｓ２７）について説明する。図１９は、フロントノード２０１による受付フロントノード用リクエスト待ち受け処理の処理フローの一例を示すフローチャートである。当該処理では、クライアント端末２００３から、データの格納を要求するＳＥＴリクエストと、格納済みデータの読み出しを要求するＧＥＴリクエストとを少なくとも受け付ける。ＳＥＴリクエストには、ユーザが指定したキーと格納したいデータとが渡される。また、ＧＥＴリクエストには、ユーザが指定したキーが渡される。

図１９に示すように、フロントノード２０１（より具体的には、受付フロントノード処理部１１１のアクセス要求受付手段１１１１）は、クライアント端末２００３に対する受付フロントノードとしてリクエスト待ちうけ状態にある時に（ステップＳ２１０１）、ネットワーク通信その他の通信手段を介してクライアント端末２００３からのリクエストを受け取る（ステップＳ２１０２）。

クライアント端末２００３からのリクエストを受け付けると、フロントノード２０１（より具体的には、受付フロントノード処理部１１１の担当フロントノード検索手段１１１２）は、まず受け取ったリクエストに含まれるキーを元にキーＩＤを算出する（ステップＳ２１０３）。ここでは、キーＩＤとして、ユーザが指定したキーを元にハッシュ関数を用いてメッセージダイジェストとなるハッシュ値を求める。ただし、ユーザが指定したキーをそのまま使うと他のユーザが同じキーを使った場合に値が被るため、ユーザ名＋ホームディレクトリ＋ユーザ指定のキーといったように、固有な値となるよう、予め定めたルールに基づいてキーに情報を足したものに対しハッシュ値を求める。求めたハッシュ値から以下のようにして担当するフロンドノードが分かる。

本例では、算出したキーＩＤを元に、担当フロントノードを検索する（ステップＳ２１０４）。ここで、担当フロントノード検索手段１１１２は、例えば、算出したキーＩＤを含むＦＩＮＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストをノードＩＤ管理サーバ２０４に送信してもよい。担当フロントノードが見つかると、担当フロントノード検索手段１１１２は、見つかった担当フロントノード２０１に、クライアント端末から受け付けたリクエスト内容を転送する（ステップＳ２１０５）。

その後、所定の時間、担当フロントノードからリクエストの処理結果の返信を待ち、処理結果を受け取ると、要求元のクライアント端末２００３に結果を返却する（ステップＳ２１０６，Ｓ２１０７）。

また、図２０は、フロントノード２０１による担当フロントノード用リクエスト待ち受け処理の処理フローの一例を示すフローチャートである。当該処理では、受付フロントノードから転送される、データの格納を要求するＳＥＴリクエストと、格納済みデータの読み出しを要求するＧＥＴリクエストとを少なくとも受け付ける。なお、図２０に示す例では、さらに、他のフロントノードから要求されるリクエストであり、当該フロントノードの退避用キーＩＤテーブルの読み出しを要求するリクエストであるＨＡＶＥ＿ＣＡＣＨＥリクエストを受け付けている。ＳＥＴリクエストには、キーと格納したいデータとが渡される。また、ＧＥＴリクエストには、キーが渡される。また、ＨＡＶＥ＿ＣＡＣＨＥリクエストには、例えば、エントリ単位の読み出しであればキーやキーＩＤが渡され、テーブル単位の読み出しであればフロントノードＩＤが渡される。

図２０に示すように、フロントノード２０１（より具体的には、担当フロントノード処理部１１２のアクセス要求受付手段１１２１）は、担当フロントノードとしてリクエスト待ちうけ状態にある時に（ステップＳ２２０１）、ネットワーク通信その他の通信手段を介して他のノードからリクエストを受け取ると、受け取ったリクエストを処理する（ステップＳ２２０２〜Ｓ２２０８）。より具体的には、受け取ったリクエストの種類を確認して、対応する処理を行う。

アクセス要求受付手段１１２１は、受け付けたリクエストがＳＥＴリクエストであった場合、ＳＥＴリクエスト受付処理を実行する（ステップＳ２２０３のＹｅｓ，Ｓ２２０４）。

また、アクセス要求受付手段１１２２は、受け付けたリクエストがＧＥＴリクエストであった場合、ＧＥＴリクエスト受付処理を実行する（ステップＳ２２０５のＹｅｓ，Ｓ２２０６）。

また、アクセス要求受付手段１１２２は、受け付けたリクエストがＨＡＶＥ＿ＣＡＣＨＥリクエストであった場合、ＣＡＣＨＥリクエスト受付処理を実行する（ステップＳ２２０７のＹｅｓ，Ｓ２２０７）。

以下、担当フロントノードとして動作するフロントノード２０１が行う各リクエスト処理について説明する。図２１は、担当フロントノードとしてのフロントノード２０１によるＳＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。当該ＳＥＴリクエスト受付処理では、担当ストレージノード処理部１１２の担当ストレージノード検索手段１１２２が、次の処理を行う。なお、このリクエストでは、ユーザが指定したキーと格納対象のデータ（メタデータを含む）とが渡される。なお、格納対象のデータとともにメタデータの全てまたは一部を渡してもよい。

担当ストレージノード検索手段１１２２は、ＳＥＴリクエストを受け付けると（ステップＳ２３０１）、引数で渡されたユーザ指定キーと、上記と同じ方法により算出したキーＩＤと、メタデータと、有効期間と、１次記憶装置上にキャッシュとして保存したデータのアドレスとを対応づけて、キーＩＤテーブルに登録する（ステップＳ２３０２，Ｓ２３０３）。また、データに対しメッセージダイジェスト値を算出しコンテンツＩＤとする。

次いで、得たコンテンツＩＤとメタデータに含まれる着目データ特徴の値（本例では、データ長）とを元に、今回のリクエストの担当となるストレージノードを検索する（ステップＳ２３０４）。ここでは、コンテンツＩＤと着目データ特徴の値とを引数に、ノードＩＤ管理サーバ２０４にＦＩＮＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを送信することにより、担当ストレージノードのＩＰアドレスを得る。

担当ストレージノードが見つかると、担当ストレージノード検索手段１１２２は、見つかった担当ストレージノード２０２に、ＳＥＴリクエストを発行し、結果を待つ（ステップＳ２３０５）。正常に書き込めた旨の結果を得ると、担当ストレージノード検索手段１１２２は、キーＩＤテーブルの内容を更新する（ステップＳ２３０６，Ｓ２３０７）。ここでは、更新日時などのメタデータを更新する。

次いで、担当ストレージノード検索手段１１２２は、必要に応じてキーＩＤテーブル上の情報を冗長化する（ステップＳ２３０８）。これは、担当フロントノードが破損した場合でもデータを書き込んだストレージノード２０２にアクセスできるようにするための処理である。当該処理では、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇの隣のノードにキーＩＤテーブルの内容を残すために、コピー処理を実行する。具体的には、自ノードのフロントノードＩＤを引数に、ノードＩＤ管理サーバ２０４にＮＥＸＴ＿ＦＲＯＮＴ＿ＮＤＥリクエストを送信し、隣の担当フロントノードの情報（ＩＰアドレス）を得る。得た情報を元に、隣の担当フロントノードにアクセスし、キーＩＤテーブルに保存した今回のデータ（ただし、データアドレスは０でクリアされたもの）をコピーする。これを冗長化したい回数分、繰り返す。

最後に、要求元のフロントノード（受付フロントノード）に、書き込み結果を返す（ステップＳ２３０９）。

また、図２２は、担当フロントノードとしてのフロントノード２０１によるＧＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。当該ＧＥＴリクエスト受付処理では、担当ストレージノード処理部１１２の担当ストレージノード検索手段１１２２が、次の処理を行う。なお、このリクエストでは、ユーザが指定したキーが渡される。

担当ストレージノード検索手段１１２２は、ＧＥＴリクエストを受け付けると（ステップＳ２４０１）、引数で渡されたユーザ指定キーを元に、上記と同じ方法によりキーＩＤを算出して、算出されたキーＩＤがキーＩＤテーブルに登録されているか否かを確認する（ステップＳ２４０２）。キーＩＤテーブルに登録されている場合（ステップＳ２４０３のＹｅｓ）、キャッシュの有効期間内であるか確認する（ステップＳ２４０４）。もしキャッシュの有効期間内であってデータアドレスが有効なアドレスを示していれば、キャッシュエリアから該当データを読み出し、要求元のフロントノード（受付フロントノード）に返却する（ステップＳ２４０５，Ｓ２４１０）。なお、このケースが最もアクセス応答が早い。

一方、キーＩＤテーブルに指定されたキーのキーＩＤが登録されていない場合（ステップＳ２４０３のＮｏ）、近隣のフロントノードに当該キーＩＤに関するエントリが保全されていないかを問い合わせる（ステップＳ２４１１）。この問い合わせは、例えば、自身のフロントノードＩＤを引数に、ノードＩＤ管理サーバ２０４にＮＥＸＴ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストを送信し、得たＩＰアドレスにＨＡＶＥ＿ＣＡＣＨＥリクエストを送信することにより行う。ＨＡＶＥ＿ＣＡＣＨＥリクエストには、算出したキーＩＤを指定する。冗長化された情報が問い合わせたフロントノードに保持されていれば、担当ストレージノードが捜索できるコンテンツＩＤと着目データ特徴の値とを得ることができる。

また、キャッシュの有効期間外であっても、キーＩＤテーブルに今回のキーＩＤを含むエントリが登録されていれば、そこからコンテンツＩＤと着目データ特徴の値を得ることができる。

コンテンツＩＤと着目データ特徴の値とを得ると、担当ストレージノード検索手段１１２２は、得たコンテンツＩＤと着目データ特徴の値（本例では、データ長）とを元に、リクエストされたデータを格納している担当ストレージノードを検索する（ステップＳ２４０６）。ここでは、コンテンツＩＤと着目データ特徴の値とを引数に、ノードＩＤ管理サーバ２０４にＦＩＮＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを送信することにより、担当ストレージノードのＩＰアドレスを得る。

担当ストレージノードが見つかると、担当ストレージノード検索手段１１２２は、見つかった担当ストレージノード２０２に、コンテンツＩＤを指定したＧＥＴリクエストを発行し、結果を待つ（ステップＳ２４０７）。正常に読み込めた旨の結果を得ると、担当ストレージノード検索手段１１２２は、キーＩＤテーブルの内容およびキャッシュエリアを更新する（ステップＳ２４０８，Ｓ２４０９）。ここでは、読み出したデータをキャッシュエリアに記憶させるとともに、更新日時、データアドレスなどのメタデータを更新する。

そして、要求元のフロントノード（受付フロントノード）に、読み出し結果を返す（ステップＳ２４１０）。

次に、ストレージノード２０２の動作について説明する。図２３は、ストレージノード２０２の動作の一例を示すフローチャートである。図２３に示す例では、ストレージノード２０２は、立ち上がると、ストレージノードのサービスプログラムが起動される（ステップＳ３１）。そして、ストレージノード２０２は、サービスプログラムに従って以下の処理を行う（ステップＳ３２〜Ｓ３６）。なお、ストレージノード２０２は、まず初期化処理として、コンテンツＩＤテーブルなどのメモリをクリアし、過去に保存していた情報があればメモリ上へ展開し状態を復帰する。また、他のノードと情報をやりとりできるようネットワーク通信用ソケットを作成する。必要であれば、ＩｎｆｉｎｉＢａｎｄなどの通信手段も起動する。

必要な初期化が終わると、ストレージノード２０２は、自身のノードＩＤをＩＰアドレスなどの当該ストレージノード２０２に固有な情報を元にＳＨＡ−１等のアルゴリズムを用いて決定する（ステップＳ３２）。

次いで、ストレージノード２０２は、決定したストレージノードＩＤと、自身のＩＰアドレスなどの情報を引数に、ノードＩＤ管理サーバ２０４に登録要求（ＡＤＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエスト）を行う（ステップＳ３３）。なおノードＩＤ管理サーバ２０４に当該ストレージノード２０２を初めて登録する前に、対応特徴に応じた初期化やチューニングを行っておく必要がある。本実施例で着目しているデータの特徴はデータ長のため、２次記憶装置に対し、担当するデータ長に応じたセグメントサイズで保存領域を分割しておく。また必要に応じて、フロントノードとのパスでＭＴＵサイズを変えるなどのチューニングを行ってもよい。ストレージノードの登録要求には、ＩＰアドレスの他に、ＭＡＣアドレスなどのノードが持つ固有な情報を含めてもよい。また、他にノードＩＤ管理サーバ２０４に登録しておく情報があれば追加する。ここで、もし登録が失敗した場合、エラー処理を行って終了してもよい（ステップＳ３４のＮｏ）。例えば、ストレージノード２０２は、サービスプログラムを終了させて、当該ストレージノード２０２ではサービスを提供しない。

登録が成功した場合は、次回以降同じノードＩＤを利用できるように、登録完了したノードＩＤを２次記憶装置に記憶させる（ステップＳ３５）。そして、ストレージノード２０２は、フロントノード２０１からの要求を待ち受ける状態に入る（ステップＳ３６）。

また、ストレージノード２０２は、終了割り込みを受け付けると終了処理を実行する（ステップＳ３７，Ｓ３８）。ここでは、次回立ち上げた時に同じデータ内容で動作できるようコンテンツＩＤテーブルを２次記憶装置に保存し、プログラムを終了する。

次に、ストレージノード２０２によるリクエスト待ち受け処理（図２３のステップＳ３６）について説明する。図２４は、ストレージノード２０２によるリクエスト待ち受け処理の処理フローの一例を示すフローチャートである。当該処理では、フロントノード２０１から、データの格納を要求するＳＥＴリクエストと、格納済みデータの読み出しを要求するＧＥＴリクエストとを少なくとも受け付ける。ＳＥＴリクエストには、格納したいデータ（メタデータを含む）が渡される。なお、コンテンツＩＤを含んでいてもよい。また、ＧＥＴリクエストには、コンテンツＩＤが渡される。

図２４に示すように、ストレージノード２０２（より具体的には、アクセス要求受付手段２１１）は、リクエスト待ちうけ状態にある時に（ステップＳ３１０１）、ネットワーク通信その他の通信手段を介してフロントノード２０１からリクエストを受け取ると、受け取ったリクエストを処理する（ステップＳ３１０２〜Ｓ３１０６）。より具体的には、受け取ったリクエストの種類を確認して、対応する処理を行う。

アクセス要求受付手段２１１は、受け付けたリクエストがＳＥＴリクエストであった場合、ＳＥＴリクエスト受付処理を実行する（ステップＳ３１０３のＹｅｓ，Ｓ３１０４）。

また、アクセス要求受付手段２１１は、受け付けたリクエストがＧＥＴリクエストであった場合、ＧＥＴリクエスト受付処理を実行する（ステップＳ３１０５のＹｅｓ，Ｓ３１０６）。

以下、ストレージノード２０２が行う各リクエスト処理について説明する。図２５は、ストレージノード２０２によるＳＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。当該ＳＥＴリクエスト受付処理では、アクセス実行手段２１２が、次の処理を行う。なお、このリクエストでは、格納対象のデータ（メタデータを含む）が渡される。

アクセス実行手段２１２は、引数で渡されたデータからコンテンツＩＤを算出する（ステップＳ３２０１）。ここでは、データに対しメッセージダイジェスト値を算出しコンテンツＩＤとする。

次いで、受け取ったデータを２次記憶装置に格納する（ステップＳ３２０２）。格納しおえると、コンテンツＩＤテーブルを更新する（ステップＳ３２０３）。ここでは、コンテンツＩＤと、データの格納先アドレスとを含む情報をコンテンツＩＤテーブルに登録する。

最後に、要求元のフロントノード（担当フロントノード）に、書き込み結果を返す（ステップＳ３２０４）。

また、図２６は、ストレージノード２０２によるＧＥＴリクエスト受付処理の処理フローの一例を示すフローチャートである。当該ＧＥＴリクエスト受付処理では、アクセス実行手段２１２が、次の処理を行う。なお、このリクエストでは、取得するデータの識別子としてコンテンツＩＤが渡される。

アクセス実行手段２１２は、引数で渡されたコンテンツＩＤをキーに自身が持つコンテンツＩＤテーブルを参照する（ステップＳ３３０１）。そのコンテンツＩＤに関するエントリが存在すれば、データの格納先である２次記憶装置内のアドレスとデータ長とが得られるので、データを読み出す（ステップＳ３３０２）。そして、読み出したデータを要求元の担当フロントノードにネットワークインタフェース部を通して送信する（ステップＳ３３０３）。このとき、正常に読みだせたか否かを示す読み出し結果の情報を含めてもよい。

次に、本実施形態のストレージシステム全体の動作について簡単に説明する。本実施形態のストレージシステムの動作は、大別すると、立ち上げ動作と、データ格納動作と、データ読出動作と、ノードの追加や削除等の構成変更動作とに分かれる。

図２７は、本実施形態のストレージシステムの立ち上げ動作の一例を示すシーケンス図である。図２７に示す例では、フロントノードＡ（２０１Ａ）、フロントノードＢ（２０１Ｂ）、ストレージノード１（２０２−１）およびストレージノード２（２０２−２）がそれぞれノードＩＤ管理サーバ（２０４）に登録要求を行っている（Ｓｅｑ０１，０３，０５，０７）。そして、ノードＩＤ管理サーバ２０４がそれぞれに返信を行っている（Ｓｅｑ０２，０４，０６，０８）。本実施形態では、ストレージノードが１つ以上と、フロントノードが１つ以上運用状態に入るとユーザからの操作を受け付けられるようになる。

また、図２８は、本実施形態のストレージシステムのデータ格納動作の一例を示すシーケンス図である。図２８に示す例では、クライアント端末２００３は、フロントノード２０１ＡにＳＥＴリクエストを送信する（Ｓｅｑ１１）。クライアント端末２００３からのアクセスを分散させるために、ＤＮＳを利用してＤＮＳラウンドロビンでアクセス先となるフロントノードを決定してもよい。

ＳＥＴリクエストを受け付けたフロントノード２０１Ａでは、渡されたキーを元にキーＩＤを算出した上で、ノードＩＤ管理サーバ２０４にＦＩＮＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストを送信し、担当フロントノードのＩＰアドレスを得る（Ｓｅｑ１２，１３）。本例では、フロントノード２０１ＢのＩＰアドレスを得る。

担当フロントノードのＩＰアドレスを得たフロントノード２０１Ａは、担当フロントノードであるフロントノード２０１Ｂに、受け付けたＳＥＴリクエストを転送する（Ｓｅｑ１４）。

ＳＥＴリクエストを受信したフロントノード２０１Ｂは、渡されたキーからキーＩＤを算出するとともに、データからコンテンツＩＤを算出し、算出したコンテンツＩＤと着目データ特徴の値（本例では、データ長）を引数に、ノードＩＤ管理サーバ２０４にＦＩＮＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを送信する（Ｓｅｑ１５）。本例では、担当ストレージノードのＩＰアドレスとしてストレージノード２０２−１のＩＰアドレスを得る（Ｓｅｑ１６）。

担当ストレージノードのＩＰアドレスを得たフロントノード２０１Ｂは、担当ストレージノードであるストレージノード２０２−１に、ＳＥＴリクエストを送信する（Ｓｅｑ１７）。

ＳＥＴリクエストを受けたストレージノード２０２−１は、渡されたデータを２次記憶装置に格納し、応答を返す（Ｓｅｑ１７，１８）。このとき、担当ストレージサーバ２０２−１は、受け付けたＳＥＴリクエストに含まれるデータからコンテンツＩＤを算出し、算出したコンテンツＩＤとデータの格納先とを紐づけて、コンテンツＩＤテーブルに登録する。

担当ストレージノードであるストレージノード２０２−１から正常書き込みの旨の応答を受けると、担当フロントノード２０１Ｂは、キャッシュエリアにデータを記憶させるとともに、指定されたキーと、キーＩＤと、コンテンツＩＤと、メタデータと、キャッシュエリアのデータアドレスとを紐づけて、キーＩＤテーブルに登録する。

そして、要求元であり受付フロントノードであるフロントノード２０１Ａに処理結果を送信する（Ｓｅｑ１９）。

担当フロントノードであるフロントノード２０１Ｂから処理結果を受け付けたフロントノード２０１Ａは、要求元のクライアント端末２００３に処理結果を送信する（Ｓｅｑ２０）。

また、図２９は、本実施形態のストレージシステムのデータ読出動作の一例を示すシーケンス図である。図２９に示す例では、クライアント端末２００３は、フロントノード２０１ＡにＧＥＴリクエストを送信する（Ｓｅｑ３１）。クライアント端末２００３から最初のアクセスを行うフロントノードは、例えば、ＤＮＳを利用してＤＮＳラウンドロビンでアクセス先となるフロントノードを決定してもよい。

ＧＥＴリクエストを受け付けたフロントノード２０１Ａでは、渡されたキーを元にキーＩＤを算出した上で、ノードＩＤ管理サーバ２０４にＦＩＮＤ＿ＦＲＯＮＴ＿ＮＯＤＥリクエストを送信し、担当フロントノードのＩＰアドレスを得る（Ｓｅｑ３２，３３）。本例では、フロントノード２０１ＢのＩＰアドレスを得る。

担当フロントノードのＩＰアドレスを得たフロントノード２０１Ａは、担当フロントノードであるフロントノード２０１Ｂに、受け付けたＧＥＴリクエストを転送する（Ｓｅｑ３４）。

ＧＥＴリクエストを受信したフロントノードであるフロントノード２０１Ｂは、渡されたキーからキーＩＤを算出し、算出したキーＩＤに紐づいているコンテンツＩＤおよび着目データ特徴の値（本例では、データ長）を得て、これらを引数にノードＩＤ管理サーバ２０４にＦＩＮＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストを送信する（Ｓｅｑ３５）。本例では、担当ストレージノードのＩＰアドレスとして、ストレージノード２０２−１のＩＰアドレスを得る（Ｓｅｑ３６）。

担当ストレージノードのＩＰアドレスを得たフロントノード２０１Ｂは、担当ストレージノードであるストレージノード２０２−１に、ＧＥＴリクエストを送信する（Ｓｅｑ３７）。

ＧＥＴリクエストを受けたストレージノード２０２−１は、渡されたコンテンツＩＤを元にデータの格納先アドレスを得て、２次記憶装置からデータを読み出す。そして、読み出したデータを含む応答を、要求元であるフロントノード２０１Ｂに送信する（Ｓｅｑ３８）。

担当ストレージノードであるストレージノード２０２−１から応答を受けると、フロントノード２０１Ｂは、キャッシュエリアにデータを記憶させるとともに、指定されたキーと、キーＩＤと、コンテンツＩＤと、メタデータと、キャッシュエリアのデータアドレスとを紐づけて、キーＩＤテーブルに登録する。

そして、要求元であり受付フロントノードであるフロントノード２０１Ａに処理結果を送信する（Ｓｅｑ３９）。

担当フロントノードであるフロントノード２０１Ｂから処理結果を受け付けたフロントノード２０１Ａは、要求元のクライアント端末２００３に処理結果を送信する（Ｓｅｑ４０）。

また、図３０は、本実施形態のストレージシステムのフロントノード２０１の追加動作の一例を示すシーケンス図である。図３０に示す例は、フロントノード２０１Ａが新たに追加される場合の動作の一例を示している。図３０に示す例では、まず追加予定のフロントノード２０１Ａが、自ノードのノードＩＤを指定してノードＩＤ管理サーバ２０４に隣のフロントノードの捜索要求を行う（Ｓｅｑ５１）。ここでいう隣のノードとは、担当を決めるＩＤのハッシュ空間上で、自ノードのＩＤの次に大きいノードＩＤをもつノードのことであり、フロントノード２０１Ａが追加されることによって担当範囲が変わる（減る）ノードである。これにより、フロントノード２０１ＢのＩＰアドレスを得る。

フロントノード２０１Ａは、得たＩＰアドレスを用いてフロントノード２０１ＢにキーＩＤテーブルのコピーを要求する（Ｓｅｑ５３）。これにより、フロントノード２０１Ｂが担当していたデータの登録先を特定可能な情報を得る。得た情報は、データアドレスを無効にした上で、当該フロントノード２０１ＡのキーＩＤテーブルに登録する。データアドレスの無効は、有効期間を無効な値にすることで実現できる。

以上の処理を終了しおえたら、ノードＩＤ管理サーバ２０４にノードの登録処理を行う（Ｓｅｑ５４）。ノードＩＤ管理サーバ２０４では、新たにフロントノード２０１Ａが追加されたことにより、これまでフロントノード２０１Ｂが担当していた範囲の一部をフロントノード２０１Ａの担当範囲に割り当てなおす。すでに格納済みのデータの担当範囲も変わることがあるが、キーＩＤテーブルがコピーされているので、フロントノード２０１Ａが担当フロントノードに任命されてもデータの格納先に到達できる。具体的には、Ｃｏｎｓｉｓｔｅｎｔ Ｈａｓｈｉｎｇで割り当ての変更を実現できる。

なお、ノードを削除する場合は、上述した冗長化処理を隣のフロントノードに行ったうえで、ノードＩＤ管理サーバ２０４に削除の旨を通知すればよい。なお、通知しなくても定期的に行われる死活監視処理に応答がないことによって削除されたことがわかるので、ノードＩＤ管理サーバ２０４は、削除を認識した時点でそのノードが担当していた範囲を他のノードに割り当てなおせばよい。

なお、図３１は、本実施形態のストレージシステムのストレージノード２０２の追加動作の一例を示すシーケンス図であるが、コピー対象がコンテンツＩＤテーブルおよびデータ格納領域である点と、ノードＩＤ管理サーバ２０４へのリクエストがＡＤＤ＿ＳＴＯＲＡＧＥ＿ＮＯＤＥリクエストである点以外は、着目データ特徴の担当クラス毎にフロントノードの場合と同じようにすればよいため説明を省略する。

以上のように、本実施形態によれば、データの特徴に応じて格納先（ストレージノード２０２）を選択でき、またストレージノード毎に調整が可能であるので、データ特性に応じた効果的な保存が可能である。また、本実施形態によれば、ストレージノードの２次記憶装置のブロックサイズを変えたものを複数用意しておけば、データ長というデータの特徴に応じて格納先となるストレージノードを振り分けることができる。このようなデータ格納方法を用いればフラグメントの発生が抑止できる。この他にもＨＤＤやＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの２次記憶装置の種類や、ＡＴＡ（Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）、ＳＣＣＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）、ＳＡＴＡ（Ｓｅｒｉａｌ−ＡＴＡ）やＳＡＳ（Ｓｅｒｉａｌ Ａｔｔａｃｈｅｄ ＳＣＳＩ）などのインタフェースを変更し、アクセスが早いが容量の小さいものとアクセスが遅いが容量の大きいものを用意するといった、データサイズによる使い分けや、コストパフォーマンスを考慮するといった応用例も実施できる。

また、本実施形態によれば、フロントノードとストレージノードの２層に分け、それぞれを分散させているので、担当フロントノードとストレージノード間の経路や転送手法を個別に調整することが可能である。例えば、小サイズのデータの場合はＥｔｈｅｒｎｅｔで標準的なＭＴＵ １５００のネットワーク通信で行い、大きなサイズのデータをやりとりする経路はＭＴＵ ９０００のネットワーク通信を行う。レスポンス性能を重視する場合はＩｎｆｉｎｉＢａｎｄによるＲＤＭＡやメッセージパッシングを行う、といった通信経路の個別の調整も可能である。なお、このような個別調整は、フロントノードとストレージノード間のパスを、データの特徴に応じて結びつけておくことによって簡単に可能である。

また、２層化構造であっても、フロントノードによりアクセス先の解決が行われるため、どのフロントノードにアクセスしても目的のデータに到達することが可能である。

フロントノードにデータをキャッシュする仕組みを備えており、参照系の閲覧速度の向上が期待できる。

なお、上述した構成や方法以外にも、例えば、担当フロントノードにおけるキーＩＤテーブルの保持機能をＤＢによって実現し、それ以外の機能（担当ストレージノードを検索する機能や、リクエストを担当ストレージノードに送信する機能等）は受付フロントノードが行うような構成であってもよい。

また、ノードＩＤ管理サーバ２０４を省略する場合は、各フロントノードが、ノードＩＤ管理サーバ２０４が行っていた機能（ノードの死活監視機能および担当先決定機能）を有し、それぞれがアクセス先を決定すればよい。具体的には、各フロントノードが、死活監視モジュールを有し、周辺のノードに死活監視を行ってどのようなＩＤを有するフロントノードおよびストレージノードがいるかを管理する。また、各フロントノードが、ハッシュ値に基づく担当先決定モジュールを有し、管理しているノードのＩＤを元に担当先を決定してもよい。なお、各フロントノードが各々担当先を決定するため、ノードの追加や削除のタイミングによっては担当先とされたノードに必要とされるキーＩＤやコンテンツＩＤがないことも考えられるが、各ノードが周辺ノードにキャッシュを問い合わせる機能を有していれば、他のノードから情報を得ることができる。

また、上記例では、着目データ特徴としてデータ長を用いる場合を例に示したが、用いるデータの特徴はこの限りではない。例えば、更新日時または作成日時を着目データ特徴として用いてもよい。一つの仮定として、新しいデータは再びアクセスされる可能性が高いと考える。この仮定に基づき、新しいデータを格納するストレージノードの格納媒体をＳＳＤに変更する、といった個別の調整を行ってもよい。また、フロントノードと該当ストレージノード間を１０Ｇｂｉｔ Ｅｔｈｅｒのように早い回線を設置しておいてもよい。また、逆に、古いデータを格納するストレージノードのＨＤＤを信頼性がＳＣＳＩよりも劣るＳＡＴＡインタフェースのＨＤＤを採用し、アクセスノードとの接続も１００Ｍｂｉｔ Ｅｔｈｅｒのようにしてコストを軽減することも考えられる。

さらに他の例として、ユーザＩＤ等のユーザの識別子を着目データ特徴として用いてもよい。作成ユーザによりプライオリティを付与するのに利用できる。上級職のユーザのデータはアクセス性能が高く記憶領域が冗長化されたストレージノードに格納するようにし、その他のユーザのデータは一般のストレージノードを利用するといったように分割してもよい。

また、本実施形態では、２層化構造をとっているので、フロントノードの追加や削除によって分散性の調整を行うことができる。例えば、フロントノードを増やせば、ユーザからアクセスできるノードの数を増やすことができる。また、担当フロントノードも増えるため、フロントノードが担当するキーＩＤの範囲が少なくなり、分散性が増す。

次に、本発明によるストレージシステムの最小構成について説明する。図３２は、本発明によるストレージシステムの最小の構成例を示すブロック図である。図１３２に示すように、本発明によるストレージシステムは、最小の構成要素として、フロントノード５００と、ストレージノード６００とを備える。また、フロントノード５００は、受付処理分散手段５０１と、ストレージノード決定手段５０２とを含む。また、ストレージノード６００は、２次記憶装置６０１と、要求受付処理手段６０２とを含む。

図３２に示す最小構成のストレージシステムでは、１つ以上のフロントノード５００が、ユーザからのアクセス要求を最初に受け付ける。

また、ストレージノード６００の２次記憶装置６０１が、データを格納するための記憶領域を有する。また、ストレージノード６００の要求受付処理手段６０２が、要求を受け付けて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う。また、ストレージノード６００は、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられている。

また、フロントノード５００の受付処理分散手段５０１が、ユーザからのアクセス要求を受け付け、受け付けたアクセス要求に対する処理を実行する担当を各フロントノード間で分散させる。また、ストレージノード決定手段５０２が、ユーザから受け付けたアクセス要求に対する処理を実行する担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、データの格納要求またはデータの読出要求を送信する。

従って、最小構成のストレージシステムによれば、データの格納領域を適宜調整することで、フラグメントの発生を防止またはより効果的に抑制できる。

以上、実施形態及び実施例を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。

また、上記の実施形態の一部または全部は、以下の付記のようにも記載されうるが、以下には限られない。

（付記１）ユーザからのアクセス要求を最初に受け付ける１つ以上のフロントノード（例えば、フロントノード１０１，２０１）と、要求に応じて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う１つ以上のストレージノード（例えば、ストレージノード１０２，２０２）とを備え、各ストレージノードは、データを格納するための記憶領域を有する２次記憶装置（例えば、２次記憶装置２４）と、要求を受け付けて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う要求受付処理手段（例えば、制御部２１）とを含み、各ストレージノードは、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられており、各フロントノードは、ユーザからのアクセス要求を受け付け、受け付けたアクセス要求に対する処理を実行する担当を各フロントノード間で分散させる受付処理分散手段（例えば、受付フロントノード処理部１１１）と、担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、データの格納要求またはデータの読出要求を送信するストレージノード決定手段（例えば、担当フロントノード処理部１１２）とを含むことを特徴とするストレージシステム。

（付記２）各フロントノードは、当該フロントノードを介して過去にストレージノードの２次記憶装置に書き込んだデータを一時的に保持するキャッシュエリアを有する付記１に記載のストレージシステム。

（付記３）データを識別するためのＩＤに、所定のサイズのハッシュ空間を有するハッシュ関数により得られるハッシュ値であるメッセージダイジェスト値が用いられ、各ストレージノードは、当該ノードを識別するためのストレージノードＩＤとして、ハッシュ空間と同じ空間範囲のハッシュ空間上にマッピングされるハッシュ値であって各ストレージノード間で互いに異なるハッシュ値が割り当てられている付記１または付記２に記載のストレージシステム。

（付記４）データの特徴をその内容に応じて２以上のクラスに分けたクラス毎にハッシュ空間を用意し、クラス別のハッシュ空間上に、各ストレージノードを、当該ストレージノードが対応しているデータの特徴の内容に応じて割り当て、クラス別のハッシュ空間におけるストレージノードの割り当て状況を基に、ストレージノードを担当ストレージノードに決定する付記３に記載のストレージシステム。

（付記５）データの特徴がデータ長であり、各ストレージノードは、所定のデータ長に応じたブロックサイズに分割された記憶領域を有しており、ストレージノード決定手段は、要求されたデータのデータ長に基づいて、当該データ長に応じたブロックサイズに分割された記憶領域を有するストレージノードを担当ストレージノードに決定する付記１から付記４のうちのいずれかに記載のストレージシステム。

（付記６）ストレージノード決定手段は、要求されたデータのデータ長に応じた通信方法またはアクセス手段を用いて、担当ストレージノードにデータの格納要求またはデータの読出要求を送信する付記５に記載のストレージシステム。

本発明は、例えば、クラウド環境で動作するストレージ装置を備えるシステムや、分散ストレージシステム、分散ファイルシステムとして好適に適用可能である。

１０００、２０００ ストレージシステム
１００１、２００１ フロントノード群
１０１、２０１ フロントノード
１００２、２００２ ストレージノード群
１０２、２０２ ストレージノード
１００３ ユーザ
２００２ クライアント端末
２０４ ノードＩＤ管理サーバ
１１、２１ 制御部
１２、２２ ネットワークインタフェース部
１３、２３ １次記憶装置
１３１ キーＩＤテーブルの保持領域
１３２ キャッシュエリア
２３１ コンテンツＩＤテーブルの保持領域
２３２ ワークエリア
１４、２４ ２次記憶装置
１４１ 保存用キーＩＤテーブルの保持領域
２４１ 保存用コンテンツＩＤテーブルの保持領域
２４２ データ格納領域
１１１ 受付フロントノード処理部
１１１１ アクセス要求受付手段
１１１２ 担当フロントノード検索手段
１１２ 担当フロントノード処理部
１１２１ アクセス要求受付手段
１１２２ 担当ストレージノード検索手段
２１１ アクセス要求受付手段
２１２ アクセス実行手段
２０４ ノードＩＤ管理サーバ

Claims (9)

1. ユーザからのアクセス要求を最初に受け付ける１つ以上のフロントノードと、
   要求に応じて２次記憶装置へのデータの格納または２次記憶装置からのデータの読み出しを行う１つ以上のストレージノードとを備え、
   前記各ストレージノードは、
   データを格納するための記憶領域を有する２次記憶装置と、
   要求を受け付けて前記２次記憶装置へのデータの格納または前記２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含み、
   前記各ストレージノードは、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられており、
   前記各フロントノードは、
   ユーザからのアクセス要求を受け付け、受け付けたアクセス要求に対する処理を実行する担当を前記各フロントノード間で分散させる受付処理分散手段と、
   前記担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、前記データの格納要求または前記データの読出要求を送信するストレージノード決定手段とを含む
   ことを特徴とするストレージシステム。
2. 前記各フロントノードは、当該フロントノードを介して過去にストレージノードの２次記憶装置に書き込んだデータを一時的に保持するキャッシュエリアを有する
   請求項１に記載のストレージシステム。
3. データを識別するためのＩＤに、所定のサイズのハッシュ空間を有するハッシュ関数により得られるハッシュ値であるメッセージダイジェスト値を用い、
   前記各ストレージノードは、当該ノードを識別するためのストレージノードＩＤとして、前記ハッシュ空間と同じ空間範囲のハッシュ空間上にマッピングされるハッシュ値であって各ストレージノード間で互いに異なるハッシュ値が割り当てられている
   請求項１または請求項２に記載のストレージシステム。
4. 前記特徴をその内容に応じて２以上のクラスに分けた前記クラス毎にハッシュ空間を用意し、
   前記クラス別のハッシュ空間上に、前記各ストレージノードを、当該ストレージノードが対応しているデータの特徴の内容に応じて割り当て、
   前記クラス別のハッシュ空間におけるストレージノードの割り当て状況を基に、ストレージノードを担当ストレージノードに決定する
   請求項３に記載のストレージシステム。
5. 前記特徴がデータ長であり、
   前記各ストレージノードは、所定のデータ長に応じたブロックサイズに分割された記憶領域を有しており、
   前記ストレージノード決定手段は、要求されたデータのデータ長に基づいて、当該データ長に応じたブロックサイズに分割された記憶領域を有するストレージノードを担当ストレージノードに決定する
   請求項１から請求項４のうちのいずれか１項に記載のストレージシステム。
6. 前記ストレージノード決定手段は、要求されたデータのデータ長に応じた通信方法またはアクセス手段を用いて、担当ストレージノードに前記データの格納要求または前記データの読出要求を送信する
   請求項５に記載のストレージシステム。
7. データを格納するための記憶領域を有する２次記憶装置と、要求を受け付けて前記２次記憶装置へのデータの格納または前記２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含む１つ以上のストレージノードと通信可能に接続されているノード装置であって、
   ユーザからのアクセス要求を受け付け、受け付けたアクセス要求に対する処理を実行する担当を前記各フロントノード間で分散させる受付処理分散手段と、
   前記担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、前記データの格納要求または前記データの読出要求を送信するストレージノード決定手段とを備えた
   ことを特徴とするノード装置。
8. データを格納するための記憶領域を有する２次記憶装置と、
   要求を受け付けて前記２次記憶装置へのデータの格納または前記２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含み、
   予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられており、
   当該ノードを識別するためのストレージノードＩＤとして、データを識別するためのＩＤに用いられているハッシュ空間と同じ空間範囲のハッシュ空間上にマッピングされるハッシュ値が割り当てられている
   ことを特徴とするノード装置。
9. データを格納するための記憶領域を有する２次記憶装置と、要求を受け付けて前記２次記憶装置へのデータの格納または前記２次記憶装置からのデータの読み出しを行う要求受付処理手段とを含む１つ以上のストレージノードの各々が、予め格納対象とされるデータが有する所定の特徴がとりうる内容の少なくとも１つと対応づけられており、
   １つ以上のフロントノードが、ユーザからのアクセス要求を受け付けると、受け付けたアクセス要求に対する処理を実行する担当を前記各フロントノード間で分散させ、
   前記１つ以上のフロントノードが、前記担当となった場合に、要求されたデータが有する特徴に基づいて１のストレージノードを担当ストレージノードに決定し、決定した担当ストレージノードに対して、前記データの格納要求または前記データの読出要求を送信する
   ことを特徴とするデータ管理方法。

Images