JP6515635B2 - 情報処理装置、情報処理システム、情報処理方法、及び、プログラム - Google Patents

Description

本発明は、情報処理装置、情報処理システム、情報処理方法、及び、そのためのプログラムに関する。

分散ファイルシステムの効率的な運用のため、ＧｌｕｓｔｅｒＦＳ（登録商標）に代表される、集中管理サーバ（メタデータサーバ、プロキシサーバ等）を設けず、また、ファイルパス名をハッシュ計算して格納ストアを決定するファイル単位の分散ファイルシステムがある。

一方、データの長期保管等の用途で用いられるアーカイブストレージのように、ファイルのアーカイブ保存・取り出し・削除のみに対応した単純な構造のストレージに対するニーズが存在する。特に容量・性能のスケールアウト性に強い分散ファイルシステムでは、アーカイブストレージを使用することが主流となっている。

特許文献１は、ハッシュアルゴリズムを用いて、重要なファイルの位置を不明瞭にして、セキュアなデータ記憶を実現するデータ記憶技術について開示している。

特許文献２は、集中管理型の分散ファイルシステムで起きていたボトルネックを解消し、効率化を図る技術を開示している。

特許文献３は、アーカイブストレージの基本的な動作に関する技術を開示している。

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

ファイル数が多く、ファイルサイズも均一である場合、分散ファイルシステムを構成する各ストレージノード内の各ストアの空き容量は、均一となりやすい。

しかし、ファイル数が少なく、ファイルサイズも大小様々にバラついている場合、各ストアへの空き容量は、バラつく傾向にある。各ストアの分散配置がバラついていると、特定ストアだけが先に容量超過となる。その場合、関連技術では、ストア間の格納容量の不均衡により性能が不安定になる可能性がある。

なお、ファイルパス名のハッシュ計算から格納先のストアを決定する関連技術では、空き容量に余裕のあるストアにファイルを格納できるかは運任せである、とも言える。

このような問題に対して、集中管理サーバを追加することで、空き容量に余裕のあるストアに確実に格納することは容易に考えられる。しかし、集中管理サーバが、性能のボトルネックになる場合や、管理対象が増えることで、分散ファイルシステムの管理が複雑になってしまう場合がある。

また、大きなファイルを細かくブロック分割することで各ストアに分散配置され易くする手法があるが、ファイル取り出し時にブロックの再結合などの処理が複雑になる上に、ストア障害時のファイル消失率が高くなってしまう。

特許文献１は、ハッシュアルゴリズムの出力を用いて、システムファイルの置かれる位置を決定しているが、データのセキュリティ向上が目的であり、また、ストア間の格納容量の不均衡については言及していない。

特許文献２は、集中管理型分散ファイルシステムで起きていたデータ位置情報管理サーバのボトルネックを解消するが、ストア間の格納容量の不均衡への対応については言及していない。

特許文献３は、アーカイブストレージの基本的な動作について述べたものであり、ファイルの格納における効率化等に関しては記載されていない。

以上のように、上記の特許文献の技術では、分散ファイルシステムにおいて、ストア間の空き容量の不均衡による性能の不安定が生じてしまう、という問題がある。

このため、本発明の目的は、上述した課題である、分散ファイルシステムにおいて、ストア間の空き容量の不均衡により性能が不安定になる、という問題を解決することにある。

本発明の情報処理装置は、複数のデータストアから構成される分散ファイルシステムにファイルをアーカイブ保存する、クライアント端末から構成される情報処理装置であって、
ファイルパス名のハッシュ計算を行うハッシュ計算手段と、前記ハッシュ計算手段に、前記ファイルパス名のハッシュ計算を指示し、前記ハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量に基づいて、前記データストアに前記ファイルをアーカイブ保存する分散配置エージェント手段と、を包含する。

本発明の情報処理方法は、複数のデータストアから構成される分散ファイルシステムにファイルをアーカイブ保存する、クライアント端末から構成される情報処理方法であって、ファイルパス名のハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量に基づいて、前記データストアに前記ファイルをアーカイブ保存する。

本発明のコンピュータプログラムは、ファイルパス名のハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量に基づいて、前記データストアに前記ファイルをアーカイブ保存する処理をコンピュータに実行させる。

本発明によれば、分散ファイルシステムにおいて、ストア間の空き容量の不均衡が解消され、性能の安定性を確保できる効果を奏する。

図１は、情報処理システムの構成の一例を示すブロック図である。 図２は、分散配置テーブルの構成の一例を示す図である。 図３は、情報処理システムの動作（アーカイブ領域をマウントし、各データストアの空き容量を確認する動作）を示すシーケンス図である。 図４は、クライアント内分散ファイルＩＯ部の動作（ファイルのアーカイブ保存）を示すフローチャートである。 図５は、クライアント内分散ファイルＩＯ部の動作（アーカイブファイルの取出し）を示すフローチャートである。 図６は、クライアント内分散ファイルＩＯ部の動作（アーカイブファイルの削除）を示すフローチャートである。 図７は、第二の実施形態に係る、情報処理装置の構成の一例を示すブロック図である。

＜第一の実施形態＞
本発明の第一の実施の形態について、図面を参照して詳細に説明する。

図１は、情報処理システム１０の構成の一例を示すブロック図である。

情報処理システム１０は、情報処理装置１１と、分散ファイルシステム００１を構成するストレージノード２００Ａ、２００Ｂと、それらを接続するネットワーク３００とを含んで構成される。

情報処理装置１１は、クライアント端末１００Ａ、及び、１００Ｂから構成される。

なお、図１では、情報処理装置１１は、クライアント端末１００Ａ、１００Ｂのように、２つの端末構成要素を有する場合を例示するが、３個以上の端末構成要素を含んでもよい。

また、下記では、クライアント端末１００Ａまたはクライアント端末１００Ｂを示す場合、説明の都合上、クライアント端末１００（１００Ａ、１００Ｂ）またはクライアント端末１００のようにも記載する。同様の記載は、他の各部にも適用されるものとする。

クライアント端末１００（１００Ａ、１００Ｂ）は、ローカルディスク１０１（１０１Ａ、１０１Ｂ）、通信部１０２（１０２Ａ、１０２Ｂ）、及び、クライアント内分散ファイルＩＯ（Ｉｎｐｕｔ Ｏｕｔｐｕｔ）部１０３（１０３Ａ、１０３Ｂ）から構成される。

ローカルディスク１０１（１０１Ａ、１０１Ｂ）は、ファイルを格納する。

通信部１０２（１０２Ａ、１０２Ｂ）は、ネットワーク３００を介して、クライアント端末１００（１００Ａ、１００Ｂ）と分散ファイルシステム００１を構成するストレージノード２００（２００Ａ、２００Ｂ）との通信を行う。

クライアント内分散ファイルＩＯ部１０３（１０３Ａ、１０３Ｂ）は、分散配置エージェント部１０４（１０４Ａ、１０４Ｂ）、分散配置テーブル１０５（１０５Ａ、１０５Ｂ）、ソルト値１０６（１０６Ａ、１０６Ｂ）、及び、ハッシュ計算部１０７（１０７Ａ、１０７Ｂ）から構成される。

分散配置エージェント部１０４（１０４Ａ、１０４Ｂ）は、ハッシュ計算部１０７（１０７Ａ、１０７Ｂ）がファイルパス名に対しハッシュ計算を行って得られたファイルパス名を有するデータストア２０１（２０１Ａ、２０１Ｂ）の空き容量を検出する。そして、分散配置エージェント部１０４（１０４Ａ、１０４Ｂ）は、その空き容量が分散配置テーブル１０５（１０５Ａ、１０５Ｂ）で空き容量が多いデータストアのものか確認し、ローカルディスク１０１（１０１Ａ、１０１Ｂ）に格納されているファイルをそこに保存する。なお、上記のハッシュ計算は、ソルト値１０６（１０６Ａ、１０６Ｂ）を加えて行うことも可能である。

分散配置テーブル１０５（１０５Ａ、１０５Ｂ）は、データストア２０１（２０１Ａ、２０１Ｂ）の空き容量の情報を格納する。

ソルト値１０６（１０６Ａ、１０６Ｂ）は、固定された有限数の値で、例えば、ＣＡ、Ｋ０等である。

ハッシュ計算部１０７（１０７Ａ、１０７Ｂ）は、ファイルパス名のハッシュ計算を行う。なお、ハッシュ計算は、ハッシュ関数等を用いて行うが、一般に広く用いられているため、ハッシュ関数に関する詳細な説明は省略する。また、ハッシュ関数については、例えば、単一のハッシュ関数に限定せず複数のハッシュ関数を用いる、等としてもよい。

ストレージノード２００（２００Ａ、２００Ｂ）は、データストア２０１（２０１Ａ、２０１Ｂ）、通信部２０２（２０２Ａ、２０２Ｂ）、及び、ノード内分散ファイルＩＯ部２０３（２０３Ａ、２０３Ｂ）から構成される。

データストア２０１（２０１Ａ、２０１Ｂ）は、ファイルを格納する。

通信部２０２（２０２Ａ、２０２Ｂ）は、ネットワーク３００を介して、クライアント端末１００（１００Ａ、１００Ｂ）との通信を行う。

ノード内分散ファイルＩＯ部２０３（２０３Ａ、２０３Ｂ）は、分散配置マネージャ部２０４（２０４Ａ、２０４Ｂ）を有する。

分散配置マネージャ部２０４（２０４Ａ、２０４Ｂ）は、複数のストレージノード２００（２００Ａ、２００Ｂ）から構成される分散ファイルシステム００１におけるファイルの配置を管理する。

分散ファイルシステム００１は、複数の各ストレージノード２００（２００Ａ、２００Ｂ）を束ねて一つのストレージシステムとして動作する。

ネットワーク３００は、情報処理装置１１を構成するクライアント端末１００と分散ファイルシステム００１を構成するストレージノード２００を接続する。なお、ネットワーク３００は、有線ネットワーク、無線ネットワーク、または、それらの混在のいずれで構成されてもよい。

ここで、通信部１０２、分散配置エージェント部１０４、ハッシュ計算部１０７、通信部２０２、及び、分散配置マネージャ部２０４は、例えば、論理回路等のハードウェア回路で構成される。

ローカルディスク１０１、及び、データストア２０１は、例えば、ディスク装置、半導体メモリ等の記憶装置で構成される。

分散配置テーブル１０５、及び、ソルト値１０６は、例えば、クライアント内分散ファイルＩＯ部１０３内の図示されないメモリに格納される。

また、クライアント端末１００（１００Ａ、１００Ｂ）と、ストレージノード２００（２００Ａ、２００Ｂ）は、それぞれ、コンピュータ装置によって実現されてもよい。この場合、通信部１０２、分散配置エージェント部１０４、及び、ハッシュ計算部１０７と、通信部２０２及び分散配置マネージャ部２０４は、それぞれコンピュータであるクライアント端末１００またはストレージノード２００のそれぞれのプロセッサが、図示されないメモリ上のプログラムを実行することで実現される制御回路であってもよい。プログラムは、不揮発性メモリに格納されてもよい。

ところで、本実施形態の情報処理システム１０におけるファイルのアーカイブ処理は、以下に示す、アーカイブ保存、アーカイブ取り出し、及び、アーカイブ削除の３機能を有していればよいものとする。

アーカイブ保存について説明する。情報処理システム１０は、ローカルディスク１０１のオリジナルファイルのファイルパス名のハッシュ計算により求められる格納先のストアでは、各格納先のストア（データストア２０１）の空き容量に偏りが発生する場合がある。この場合、アーカイブ保存では、空き容量の多いデータストア２０１にファイルを格納するまで、ファイルパス名にソルト値１０６を加えた上でハッシュ計算を繰り返し、ファイルを保存する。

アーカイブ取り出し時には、情報処理システム１０は、オリジナルファイルパス名でのハッシュ計算による格納先のストアにファイルが存在しない場合は、ファイルパス名にソルト値１０６を加えた上でハッシュ計算を繰り返し、データストア２０１からファイルを取り出す。全てのソルト値でもファイルが存在しなければ、情報処理システム１０は、最初から存在しないファイルとして応答をユーザ端末に返す。

アーカイブ削除時には、情報処理システム１０は、アーカイブ取出時と同様の手順で、データストア２０１内のファイルを削除する。

以下、アーカイブ領域をマウントし、各データストアの空き容量を確認する動作については、図３にて説明する。

また、クライアント端末１００側のローカルファイルをアーカイブに保存する動作については、図４にて説明する。

そして、アーカイブファイルを取得する動作については図５にて、アーカイブファイルを削除する動作については図６にて説明する。

図２は、分散配置テーブル１０５の構成の一例を示す図である。図２に示すように、分散配置テーブル１０５は、各データストア２０１（データストア名）の空き容量の値を格納する。たとえば、データストアＡはデータストア２０１Ａ、データストアＢはデータストア２０１Ｂに対応する。

分散配置テーブル１０５は、例えば、各データストア２０１を空き容量の大きい順にソートする。さらに、分散配置テーブル１０５は、例えば、空き容量の大きい順にソートされたデータにおいて、所定の空き容量、もしくは、所定の順位の箇所に所定の閾値を設けている。これにより、分散配置エージェント部１０４は、閾値より空き容量が多いデータストア２０１を空き容量の大きいストア（上位の空きストア）として指定する。

なお、図２に示したデータストア名（データストアＡ〜Ｄ）は、図１のデータストア２０１（２０１Ａ、２０１Ｂ）の各要素（データストア２０１Ａ、データストア２０１Ｂ）の単位で割り当てられたものでもよいし、データストア２０１（２０１Ａ、２０１Ｂ）をさらに分割した要素に割り当てられてもよい。データストア名の単位は、データの格納の用途、目的等に応じて、適宜、設定または変更できるものとする。

ところで、上記の説明では、空き容量を評価関数とし分散配置テーブル１０５を作成しているが、ストア間の格納容量の均衡を保つことができる指標であれば、空き容量に限定せず、他のパラメータに置き換えてもよい。

図３は、情報処理システム１０の動作（アーカイブ領域をマウントし、各データストア２０１の空き容量を確認する動作）を示すシーケンス図である。

まず、ユーザは、クライアント端末１００とネットワーク３００を介して接続する図示しないユーザ端末等から、クライアント内分散ファイルＩＯ部１０３に対して、分散ファイルシステム００１をファイルシステムとして利用可能にするために、分散ファイルシステム００１をマウント実行する命令を出す（ステップＡ１）。そして、クライアント内分散ファイルＩＯ部１０３（分散配置エージェント部１０４の動作とも記載できるが、以下、本図では、このように記載）は、ノード内分散ファイルＩＯ部２０３（分散配置マネージャ部２０４の動作とも記載できるが、以下、本図では、このように記載）に対して、分散ファイルシステム００１のマウント要求を行う（ステップＡ２）。

次に、ノード内分散ファイルＩＯ部２０３は、通信部２０２を介して各データストア２０１の「データストア名、空き容量」情報をネットワーク３００にブロードキャストする（ステップＡ３）。

クライアント内分散ファイルＩＯ部１０３は、通信部２０２を介してノード内分散ファイルＩＯ部２０３からのブロードキャストを受け取り、「データストア名、空き容量」からなる分散配置テーブル１０５（図２）を作成または更新する。例えば、空き容量順にソートして空き容量がより多い方のデータストア２０１を分散配置テーブル１０５に残す（ステップＡ４）。

一方、ノード内分散ファイルＩＯ部２０３は、マウント実施とマウント完了通知を返送する（ステップＡ５）。

そして、ユーザは、ユーザ端末を介して、マウント完了通知を受け取る（ステップＡ６）。

なお、ノード内分散ファイルＩＯ部２０３は、一定時間（例えば、３００秒等）ごとに、各データストア２０１の「データストア名、空き容量」情報を、通信部２０２を介してブロードキャストする（ステップＡ７）。

そして、クライアント内分散ファイルＩＯ部１０３は、ステップＡ４と同様に、ブロードキャストを受け取り、分散配置テーブル１０５を作成または更新し、例えば、空き容量順にソートして空き容量のより多い方のデータストア２０１を分散配置テーブル１０５に残す（ステップＡ８）。

図４は、クライアント内分散ファイルＩＯ部１０３の動作（ファイルのアーカイブ保存）を示すフローチャートである。

まず、ユーザが、ユーザ端末を介して、例えば、ファイル名「ｆｉｌｅＡ」のファイルのアーカイブ保存のための指示をクライアント端末１００に対して実行する。そして、クライアント内分散ファイルＩＯ部１０３は、ファイル名「ｆｉｌｅＡ」のアーカイブ保存命令を受ける（ステップＢ１）。

次に、クライアント内分散ファイルＩＯ部１０３（以下、分散配置エージェント部１０４の動作は分散配置エージェント部１０４と記載）は、「ｆｉｌｅＡ」のファイルパス名から、ハッシュ計算部１０７にハッシュ計算を指示し、格納先のストア（実際は、そのファイルパス名）を算出する（ステップＢ２）。

そして、ステップＢ２の算出結果に基づいて、分散配置エージェント部１０４は、ステップＢ２で算出した格納先のデータストア２０１（以下、格納ストア、または、ストアとも記載）が、分散配置テーブル１０５において十分な空き容量を有する上位の空きストアに属するか（空き容量が所定の閾値より大きいか）判定する（ステップＢ３）。

空き容量が十分にある上位の空きストアに格納される場合（ステップＢ３でＹｅｓの場合）、分散配置エージェント部１０４は、ステップＢ２で算出した格納ストアに、ファイル名「ｆｉｌｅＡ」でアーカイブ保存を実行する（ステップＢ４）。

そして、分散配置エージェント部１０４は、ファイル名「ｆｉｌｅＡ」のアーカイブ保存完了を、ノード内分散ファイルＩＯ部２０３（以下、ノード内分散ファイルＩＯ部２０３の動作は分散配置マネージャ部２０４と記載）から受け取る（ステップＢ５）。

一方、ステップＢ３でＮｏの場合、分散配置エージェント部１０４は、ファイルパス名は元のままで、ファイルパス名にソルト値１０６を付け、格納ストアをハッシュ計算部１０７に命令して算出する（ステップＢ６）。

そして、分散配置エージェント部１０４は、ステップＢ６で算出した格納ストアが、分散配置テーブル１０５の上位の空きストアに属するか（所定の閾値より大きいか）繰り返し判定する（ステップＢ７）。なお、ステップＢ７で、分散配置エージェント部１０４は、上記の動作を、判定Ｙｅｓまたは準備していたソルト値を使い果たすまで繰り返す。

その後（ステップＢ７でＹｅｓ）、分散配置エージェント部１０４は、ステップＢ７で算出された格納ストアに、ファイル名「ｆｉｌｅＡ」でアーカイブ保存を実行し（ステップＢ８）、ステップＢ５の動作を行う。

以上により、ファイル名「ｆｉｌｅＡ」のアーカイブ保存は、完了する。

図５は、クライアント内分散ファイルＩＯ部１０３の動作（アーカイブファイルの取出し）を示すフローチャートである。

まず、ユーザが、ユーザ端末を介して、ファイル名「ｆｉｌｅＡ」のアーカイブ取出のための指示をクライアント端末１００に対して実行する。そして、分散配置エージェント部１０４は、ファイル名「ｆｉｌｅＡ」のアーカイブ取出命令を受ける（ステップＣ１）。

次に、分散配置エージェント部１０４は、「ｆｉｌｅＡ」のファイルパス名から、ハッシュ計算部１０７にハッシュ計算を指示して、格納ストアを算出し、アーカイブ取出実行できるか判定する（ステップＣ２）。

ステップＣ２でＹｅｓの場合、分散配置エージェント部１０４は、直前手段による格納ストアから、ファイル名「ｆｉｌｅＡ」をアーカイブ取出実行する（ステップＣ３）。

そして、分散配置エージェント部１０４は、ファイル名「ｆｉｌｅＡ」のアーカイブ取出完了を、分散配置マネージャ部２０４から受け取り（ステップＣ４）、正常終了（（ファイル名「ｆｉｌｅＡ」のアーカイブ取出完了）する。

一方、ステップＣ２でＮｏの場合、分散配置エージェント部１０４は、ファイルパス名は元のままで、ファイルパス名にソルト値１０６を付けた場合のハッシュ計算をハッシュ計算部１０７に命令して格納ストアを算出し、「ｆｉｌｅＡ」が存在するか繰り返し判定する（ステップＣ５）。

ステップＣ５でＹｅｓの場合、分散配置エージェント部１０４は、直前手段による格納ストアから、ファイル名「ｆｉｌｅＡ」をアーカイブ取出実行する（ステップＣ６）。

一方、ステップＣ５でＮｏの場合、分散配置エージェント部１０４は、エラー（ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ）を、分散配置マネージャ部２０４から受け取り（ステップＣ７）、異常終了する。この場合、ファイル名「ｆｉｌｅＡ」は存在しない。

図６は、クライアント内分散ファイルＩＯ部１０３の動作（アーカイブファイルの削除）を示すフローチャートである。

なお、図６におけるクライアント内分散ファイルＩＯ部１０３の各動作は、図５における「取得」を「削除」の動作に置き換えたものである。

まず、ユーザが、ユーザ端末を介して、ファイル名「ｆｉｌｅＡ」のアーカイブ削除のための指示をクライアント端末１００に対して実行する。そして、分散配置エージェント部１０４は、ファイル名「ｆｉｌｅＡ」のアーカイブ削除命令を受ける（ステップＤ１）。

次に、分散配置エージェント部１０４は、「ｆｉｌｅＡ」のファイルパス名から、ハッシュ計算部１０７にハッシュ計算を指示して、格納ストアを算出し、アーカイブ削除実行できるか判定する（ステップＤ２）。

ステップＤ２でＹｅｓの場合、分散配置エージェント部１０４は、直前手段による格納ストアから、ファイル名「ｆｉｌｅＡ」をアーカイブ削除実行する（ステップＤ３）。

そして、分散配置エージェント部１０４は、ファイル名「ｆｉｌｅＡ」のアーカイブ削除完了を、分散配置マネージャ部２０４から受け取り（ステップＤ４）、正常終了（（ファイル名「ｆｉｌｅＡ」のアーカイブ削除完了）する。

一方、ステップＤ２でＮｏの場合、分散配置エージェント部１０４は、ファイルパス名は元のままで、ファイルパス名にソルト値１０６を付けた場合のハッシュ計算をハッシュ計算部１０７に命令して格納ファイルを算出し、「ｆｉｌｅＡ」が存在するか繰り返し判定する（ステップＤ５）。

ステップＤ５でＹｅｓの場合、分散配置エージェント部１０４は、直前手段による格納ストアから、ファイル名「ｆｉｌｅＡ」をアーカイブ削除実行する（ステップＤ６）。

一方、ステップＤ５でＮｏの場合、分散配置エージェント部１０４は、エラー（ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ）を、分散配置マネージャ部２０４から受け取り（ステップＤ７）、異常終了する（ファイル名「ｆｉｌｅＡ」は存在しない）。

以上、述べてきたように、本実施形態の情報処理システム１０は、集中管理サーバのない分散ファイルシステムのメリット（ボトルネック排除、管理の簡素化）、及び、ファイル単位管理のメリット（ブロック単位のようにブロック再結合などで処理が複雑かつオーバーヘッドにならず、ストア障害時のファイル消失リスクも軽減できる）を維持しつつ、空き容量に余裕のあるストアにデータを格納することができる。

また、上記の結果、特定のストアの容量が超過する以前に容量の最適化が実行されることで、特定ストアにＩＯが集中することなく、ストア全体にＩＯも均一化されやすくなる。その結果、情報処理システム１０は、分散ファイルストレージとしての性能も向上する。

本実施形態に係る情報処理システム１０は、以下に記載するような効果を奏する。

分散ファイルシステムにおいて、ストア間の空き容量の不均衡が解消され性能の安定性を確保できる、という効果を奏する。

その理由は、ハッシュ計算で算出したファイルパス名のデータストア２０１の空き容量に基づいて、データストア２０１にファイルをアーカイブ保存するからである。
＜第二の実施形態＞
次に、本発明の第二の実施の形態について図面を参照して詳細に説明する。

図７は、第二の実施形態に係る、情報処理装置４０の構成の一例を示すブロック図である。

情報処理装置４０は、分散配置エージェント部４１、及び、ハッシュ計算部４２から構成される。

情報処理装置４０は、複数のデータストアから構成される分散ファイルシステムにファイルをアーカイブ保存する、クライアント端末から構成される。

情報処理装置４０は、ファイルパス名のハッシュ計算を行うハッシュ計算部４２と、ハッシュ計算部４２に、ファイルパス名のハッシュ計算を指示し、ハッシュ計算で算出したファイルパス名のデータストアの空き容量に基づいて、データストアにファイルをアーカイブ保存する分散配置エージェント部４１と、を包含する。

本実施形態に係る情報処理装置４０は、以下に記載するような効果を奏する。

分散ファイルシステムにおいて、ストア間の空き容量の不均衡が解消され性能の安定性を確保できる、という効果を奏する。

その理由は、ハッシュ計算で算出したファイルパス名のデータストアの空き容量に基づいて、データストア２０１にファイルをアーカイブ保存するからである。

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

００１ 分散ファイルシステム
１０ 情報処理システム
１００（１００Ａ、１００Ｂ） クライアント端末
１０１（１０１Ａ、１０１Ｂ） ローカルディスク
１０２（１０２Ａ、１０２Ｂ） 通信部
１０３（１０３Ａ、１０３Ｂ） クライアント内分散ファイルＩＯ部
１０４（１０４Ａ、１０４Ｂ） 分散配置エージェント部
１０５（１０５Ａ、１０５Ｂ） 分散配置テーブル
１０６（１０６Ａ、１０６Ｂ） ソルト値
１０７（１０７Ａ、１０７Ｂ） ハッシュ計算部
１１ 情報処理装置
２００（２００Ａ、２００Ｂ） ストレージノード
２０１（２０１Ａ、２０１Ｂ） データストア
２０２（２０２Ａ、２０２Ｂ） 通信部
２０３（２０３Ａ、２０３Ｂ） ノード内分散ファイルＩＯ部
２０４（２０４Ａ、２０４Ｂ） 分散配置マネージャ部
３００ ネットワーク
４０ 情報処理装置
４１ 分散配置エージェント部
４２ ハッシュ計算部

Claims (10)

1. 複数のデータストアから構成される分散ファイルシステムにファイルをアーカイブ保存する、クライアント端末から構成される情報処理装置であって、
   ファイルパス名のハッシュ計算を行うハッシュ計算手段と、
   前記ハッシュ計算手段に、前記ファイルパス名のハッシュ計算を指示し、前記ハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量が所定の閾値より大きい場合に、前記データストアに前記ファイルをアーカイブ保存する分散配置エージェント手段と、
   前記複数のデータストアを前記空き容量の順番によりソートし、ソートした結果に基づいて前記閾値を設定する分散配置テーブルと、
   を包含する情報処理装置。
2. 前記分散配置テーブルは、前記ソートした結果において、所定の順位に位置する前記データストアの前記空き容量を、前記閾値に設定する、
   請求項１に記載の情報処理装置。
3. 前記分散配置エージェント手段が、前記ハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量が所定の閾値より大きくない場合に、前記ファイルパス名にソルト値を加えて前記ハッシュ計算で算出したファイルパス名のデータストアの空き容量が所定の閾値より大きい場合に、前記ファイルパス名にソルト値を加えて前記ハッシュ計算で算出したファイルパス名のデータストアに前記ファイルをアーカイブ保存する、
   請求項１または請求項２に記載の情報処理装置。
4. 請求項１乃至３のいずれか１項に記載の情報処理装置と、
   前記分散ファイルシステムと、を包含する、情報処理システム。
5. 複数のデータストアから構成される分散ファイルシステムにファイルをアーカイブ保存する、クライアント端末から構成される情報処理方法であって、
   ファイルパス名のハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量が所定の閾値より大きい場合に、前記データストアに前記ファイルをアーカイブ保存し、
   前記複数のデータストアを前記空き容量の順番によりソートし、ソートした結果に基づいて前記閾値を設定する、
   情報処理方法。
6. 前記ソートした結果において、所定の順位に位置する前記データストアの前記空き容量を、前記閾値に設定する、
   請求項５に記載の情報処理方法。
7. 前記ハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量が所定の閾値より大きくない場合に、前記ファイルパス名にソルト値を加えて前記ハッシュ計算で算出したファイルパス名のデータストアの空き容量が所定の閾値より大きい場合に、前記ファイルパス名にソルト値を加えて前記ハッシュ計算で算出したファイルパス名のデータストアに前記ファイルをアーカイブ保存する、
   請求項５または請求項６に記載の情報処理方法。
8. 複数のデータストアから構成される分散ファイルシステムにファイルをアーカイブ保存する、クライアント端末から構成される情報処理装置に、
   ファイルパス名のハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量が所定の閾値より大きい場合に、前記データストアに前記ファイルをアーカイブ保存する処理と、
   前記複数のデータストアを前記空き容量の順番によりソートし、ソートした結果に基づいて前記閾値を設定する処理と、
   を実行させるプログラム。
9. 前記ソートした結果において、所定の順位に位置する前記データストアの前記空き容量を、前記閾値に設定する処理
   を前記情報処理装置に実行させる請求項８に記載のプログラム。
10. 前記ハッシュ計算で算出した前記ファイルパス名のデータストアの空き容量が所定の閾値より大きくない場合に、前記ファイルパス名にソルト値を加えて前記ハッシュ計算で算出したファイルパス名のデータストアの空き容量が所定の閾値より大きい場合に、前記ファイルパス名にソルト値を加えて前記ハッシュ計算で算出したファイルパス名のデータストア前記ファイルをアーカイブ保存する処理
    を前記情報処理装置に実行させる請求項８または請求項９に記載のプログラム。

Images