JP2015135568A - ゲートウェイ装置、ファイルサーバシステム及びファイル分散方法 - Google Patents

Abstract

【課題】複数のファイルサーバとローカルディスクによって構成される、可用性の高いシステムを実現する。【解決手段】分散ファイルシステムは、リクエストに応じてファイル格納、ファイル読込及びファイル削除のいずれかを行う複数のファイルサーバクラスタ４０を有する。ゲートウェイ装置３０は、ファイル格納、ファイル読込及びファイル削除のいずれかを含むリクエストを送信するクライアント装置１０と分散ファイルシステムとの間でリクエストを仲介する。ゲートウェイ装置３０は、ファイルサーバクラスタの稼動状態を監視するヘルスチェック機能部と、クライアント装置１０から分散ファイルシステムへのリクエストを受信し、正常に稼働中のファイルサーバクラスタ４０の中からひとつ又は複数を選択して該リクエストを選択したファイルサーバクラスタ４０へ振り分けるデータ制御機能部とを有する。【選択図】図１

Description

本発明は、ゲートウェイ装置、ファイルサーバシステム及びファイル分散方法に関する。

昨今、ビックデータに代表される大量のデータをデータセンタに蓄積し、これを一括処理し、ビジネスに役立つ知見（情報）を得る取り組みがある。大量のデータを処理する場合に、ディスクＩ／Ｏの性能（スループット）が課題となる。そこで、ＨａｄｏｏｐのＨＤＦＳ（Ｈａｄｏｏｐ Ｄｉｓｔｒｉｂｕｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ）に代表される分散ファイルシステム技術では、大容量のファイルを細かい単位（ブロック）に分割して、複数のサーバのローカルディスクに格納し、ファイル読み込み時には、複数のサーバ（ディスク）から同時並行で読み出すことにより、高スループットを実現している（例えば、非特許文献１、“Ａｒｃｈｉｔｅｃｔｕｒｅ”、“Ｄｅｐｏｙｍｅｎｔ−Ａｄｍｉｎｉｓｔｒａｔｉｖｅ ｃｏｍｍａｎｄｓ”等の項目参照）。一方、通信事業者のサービス提供基盤や、電力又は交通等の社会インフラ事業者のシステム制御基盤においては、サービスの無停止運用が最優先課題のひとつであり、システム障害時に障害サーバを切り離し、待機サーバに切り替えることにより、高信頼性を実現している。

例えば、特許文献１に記載の技術では、クラスタシステムにおいて、スプリットブレイン（ネットワーク障害などによるサーバ間の同期不正による異常動作）が発生した際の不要なサービス停止を防ぐ方法を提案している（例えば要約参照）。

特開２０１２−１７３９９６号公報

"ＨＤＦＳ Ｈｉｇｈ Ａｖａｉｌａｂｉｌｉｔｙ Ｕｓｉｎｇ ｔｈｅ Ｑｕｏｒｕｍ Ｊｏｕｒｎａｌ Ｍａｎａｇｅｒ"、［ｏｎｌｉｎｅ］、Ｔｈｅ Ａｐａｃｈｅ Ｓｏｆｔｗａｒｅ Ｆｏｕｎｄａｔｉｏｎ、［平成２５年１１月１５日検索］、インターネット＜ｈｔｔｐ：／／ｈａｄｏｏｐ．ａｐａｃｈｅ．ｏｒｇ／ｄｏｃｓ／ｃｕｒｒｅｎｔ／ｈａｄｏｏｐ−ｙａｒｎ／ｈａｄｏｏｐ−ｙａｒｎ−ｓｉｔｅ／ＨＤＦＳＨｉｇｈＡｖａｉｌａｂｉｌｉｔｙＷｉｔｈＱＪＭ．ｈｔｍｌ＞

分散ファイルシステムでは、多数のサーバが協調して動作することにより分散処理を実現しており、サーバ台数を増やすことで処理性能を向上させることができる。一方、サーバ台数が多くなることにより、故障が発生する可能性が高くなるため、一部のサーバが正常に動作していない状態においても、システム全体としては処理を正常に継続できることが求められる。

非特許文献１に記載の技術は、ファイルシステムのメタデータを管理しているＮａｍｅＮｏｄｅの冗長化が課題となる。そのため、アクティブＮａｍｅＮｏｄｅサーバとスタンバイＮａｍｅＮｏｄｅサーバとで構成し、ＮａｍｅＮｏｄｅの障害時に、アクティブな状態にあるサーバを停止し、スタンバイ状態のサーバに処理を切り替えることで高信頼化を実現している。しかし、非特許文献１の技術では、アクティブとスタンバイ間の切り替え中にサービスが中断したり、切り替え処理が失敗してサービスが停止するリスクを抱えている。さらに、非特許文献１の技術を適用するためには、すべてのサーバのソフトウェアを更新する必要があるため、運用コスト（導入コスト）が大きいという課題があった。

特許文献１に記載の技術では、上述のように、クラスタシステムにおいて、スプリットブレインが発生した際の不要なサービス停止を防ぐ方法を提案している。しかし、特許文献１の技術は、サーバ間の同期処理に共有ストレージを使用しているが、共有ストレージの故障を考慮していないという課題がある。さらに、特許文献１の技術は、データの冗長化を考慮しておらず、分散ファイルシステムのデータ可用性を担保することができていない。

本発明は、以上の点に鑑み、複数のファイルサーバとローカルディスクによって構成される分散ファイルシステムを備えたシステムの可用性を向上させることを目的とする。

本発明の第１の解決手段によると、
ファイル格納、ファイル読込及びファイル削除のいずれかを含むリクエストを送信するクライアント装置と、該リクエストに応じたファイル処理を行う複数のファイルサーバクラスタを有する分散ファイルシステムとの間でリクエストを仲介するゲートウェイ装置であって、
前記ファイルサーバクラスタの稼動状態を監視するヘルスチェック機能部と、
前記クライアント装置から前記分散ファイルシステムへのリクエストを受信し、正常に稼働中のファイルサーバクラスタの中からひとつ又は複数を選択して該リクエストを選択したファイルサーバクラスタへ振り分けるデータ制御機能部と
を有するゲートウェイ装置が提供される。

本発明の第２の解決手段によると、
リクエストに応じてファイル格納、ファイル読込及びファイル削除のいずれかを行う複数のファイルサーバクラスタを有する分散ファイルシステムと、
ファイル格納、ファイル読込及びファイル削除のいずれかを含むリクエストを送信するクライアント装置と前記分散ファイルシステムとの間でリクエストを仲介するゲートウェイ装置と
を備え、
前記ゲートウェイ装置は、
前記ファイルサーバクラスタの稼動状態を監視するヘルスチェック機能部と、
前記クライアント装置から前記分散ファイルシステムへのリクエストを受信し、正常に稼働中のファイルサーバクラスタの中からひとつ又は複数を選択して該リクエストを選択したファイルサーバクラスタへ振り分けるデータ制御機能部と
を有するファイルサーバシステムが提供される。

本発明の第３の解決手段によると、
リクエストに応じてファイル格納、ファイル読込及びファイル削除のいずれかを行う複数のファイルサーバクラスタを有する分散ファイルシステムと、ファイル格納、ファイル読込及びファイル削除のいずれかを含むリクエストを送信するクライアント装置と前記分散ファイルシステムとの間でリクエストを仲介するゲートウェイ装置とを備えたファイルサーバシステムにおけるファイル分散方法であって、
前記ゲートウェイ装置が、
前記ファイルサーバクラスタの稼動状態を監視し、
前記クライアント装置から前記分散ファイルシステムへのリクエストを受信し、正常に稼働中のファイルサーバクラスタの中からひとつ又は複数を選択して該リクエストを選択したファイルサーバクラスタへ振り分ける前記ファイル分散方法が提供される。

本開示によれば、複数のファイルサーバとローカルディスクによって構成される分散ファイルシステムを備えたシステムの可用性を向上させることができる。

コンピュータシステム（ファイルサーバシステム）の実施例１における全体構成例を示す図である。 コンピュータシステムの実施例１を構成するアプリケーション拡張ゲートウェイ装置の構成例を示す図である。 アプリケーション拡張ゲートウェイ装置が具備するクライアントＡＰＩ機能部の処理ステップを示すフローチャートである。 アプリケーション拡張ゲートウェイ装置が具備するクラスタ設定機能部の処理ステップを示すフローチャートである。 アプリケーション拡張ゲートウェイ装置が具備するヘルスチェック機能部の処理ステップを示すフローチャートである。 アプリケーション拡張ゲートウェイ装置の具備するデータ制御機能部の処理ステップである。 アプリケーション拡張ゲートウェイ装置が具備するデータリストア機能部の処理ステップを示すフローチャートである。 アプリケーション拡張ゲートウェイ装置が保持するクラスタ情報を管理するテーブルの構成例を示す図である。 アプリケーション拡張ゲートウェイ装置が保持するデータポリシー情報を管理するテーブルの構成例を示す図である。 アプリケーション拡張ゲートウェイ装置が保持するデータインデクス情報を管理するテーブルの構成例を示す図である。 アプリケーション拡張ゲートウェイ装置が保持するクラスタ分散ルールを管理するテーブルの構成例を示す図である。 アプリケーション拡張ゲートウェイ装置が保持するデータリストアルールを管理するテーブルの構成例を示す図である。 アプリケーション拡張ゲートウェイ装置を介してファイル作成を行う処理フロー例を示すシーケンス図である。 アプリケーション拡張ゲートウェイ装置を介してファイル読出しを行う処理フロー例を示すシーケンス図である。 アプリケーション拡張ゲートウェイ装置を介してファイル削除を行う処理フロー例を示すシーケンス図である。 アプリケーション拡張ゲートウェイ装置を介してファイル検索を行う処理フロー例を示すシーケンス図である。 クライアントからアプリケーション拡張ゲートウェイ装置に対して送信するＡＰＩメッセージ例を示す図である。 コンピュータシステム（ファイルサーバシステム）の実施例２における全体構成例を示す図である。 コンピュータシステムの実施例２を構成するアプリケーション拡張ゲートウェイ装置の構成例を示す図である。 アプリケーション拡張ゲートウェイ装置の具備するクラスタ再構成機能部の処理ステップを示すフローチャートである。 アプリケーション拡張ゲートウェイ装置が保持するデータ再構成ルールを管理するテーブルの構成例を示す図である。 実施例１のゲートウェイ装置の概略シーケンス図である。

本実施の形態は、例えば、ＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）、ファイル保管システム及びデータセンタ等におけるサーバ装置と端末との間でデータを通信するネットワークシステムにおいて、端末とサーバ装置間の通信経路上に設置されるゲートウェイ装置、そのゲートウェイ装置を備えるファイルサーバシステム、及び、ファイル分散方法に関する。以下各実施例を用いて説明する。
（実施例１）
図１は、コンピュータシステム（ファイルサーバシステム）の実施例１における全体構成例を示す図である。
本実施例のコンピュータシステム（ファイルサーバシステム）は、１つ又は複数のクライアント装置（以下、単にクライアントと称する）１０と、１つ又は複数のアプリケーション拡張ゲートウェイ装置（以下、ゲートウェイ装置と称することもある）３０と、１又は複数のファイルサーバクラスタ４０とを備え、各装置がネットワーク２１又は２１を介して接続される。

クライアント１０は、ファイルを作成し及び／又はファイルを参照するアプリケーションを実行する端末である。アプリケーション拡張ゲートウェイ装置３０は、クライアント１０とファイルサーバクラスタ４０の間にあって、本実施例の機能部プログラムを実装しているサーバである。例えば、クライアント１０は、ファイル格納、ファイル読込、ファイル削除及びファイル検索のいずれかを含むリクエストを送信する。

ファイルサーバクラスタ４０はそれぞれ、データの所在や状態などのメタデータを管理する少なくとも１つのネームノード５０と、データを保持する１つ又は複数のデータノード６０を有し、１つ又は複数のファイルサーバクラスタ４０で分散ファイルシステムを構成している。

本実施例では、アプリケーション拡張ゲートウェイ装置３０とファイルサーバクラスタ４０を別々のハードウェアで構成する形態を示すが、アプリケーション拡張ゲートウェイ装置３０とファイルサーバクラスタ４０が同一のハードウェア上で動作する構成であっても構わない。

また、本実施例では、アプリケーション拡張ゲートウェイ装置３０が１台であるコンピュータシステムの構成を説明するが、複数のゲートウェイ装置３０を備えるコンピュータシステムの構成であっても構わない。その場合、複数のゲートウェイ装置３０間で情報の共有化又は同期を行う。

図２は、ゲートウェイ装置３０の構成例を示す図である。
ゲートウェイ装置３０は、例えば、１つ以上のＣＰＵ１０１と、１つ以上のネットワークインタフェース（ＮＷ Ｉ／Ｆ）１０２〜１０４と、入出力装置１０６と、メモリ１０５とを備え、各部が内部バス等の通信路１０７を介して相互に接続されるコンピュータ上に実現される。ＮＷ Ｉ／Ｆ１０２は、ネットワーク２０を介してクライアント１０と接続される。ＮＷ Ｉ／Ｆ１０３は、ネットワーク２１を介してファイルサーバクラスタのネームノード５０と相互に接続される。ＮＷ Ｉ／Ｆ１０４は、ネットワーク２１を介してファイルサーバクラスタのデータノード６０と相互に接続される。メモリ１０５には、以下に説明するクライアントＡＰＩ機能部１１１、クラスタ設定機能部１１２、ヘルスチェック機能部１１３、データ制御機能部１１４、データリストア機能部１１５及びデータポリシー設定機能部１１７の各プログラムと、クラスタ管理テーブル１２１、データインデクス管理テーブル１２２及びデータポリシー管理テーブル１２３が格納される。各プログラムは、ＣＰＵ１０１により実行されて各機能部の動作が実現される。なお、各テーブルはテーブル形式以外でもよく、適宜の記憶領域でもよい。

各プログラムは、予めゲートウェイ装置３０のメモリ１０５に格納されていても良いし、必要なときに、ゲートウェイ装置３０が利用可能な記録媒体を介して、メモリ１０５に導入されてもよい。記録媒体とは、例えば入出力装置１０６に着脱可能な記憶媒体、又は通信媒体（すなわち、ＮＷ Ｉ／Ｆ１０２〜１０４に接続する有線又は無線、光等のネットワーク、又は当該ネットワークを伝搬する搬送波やディジタル信号）を介した媒体を指す。

入出力装置１０６は、例えば管理者７０により操作されることによりデータを入力する入力部と、データを表示する表示部と有することができる。なお、入出力装置１０６は、管理者が操作する外部の管理端末と接続され、管理端末からデータを入力し、管理端末へデータを出力するようにしてもよい。

図８は、ゲートウェイ装置３０に具備されるクラスタ管理テーブル１２１の一例を示したものである。クラスタ管理テーブル１２１には、例えば、クラスタ毎に、クラスタを識別するクラスタＩＤ８０２、クラスタのネットワークアドレス（例えばＩＰアドレス）であるネームノードアドレス８０３、クラスタが正常か異常かを示す稼動状態８０４、稼動状態を更新した日時である状態変更日付８０５、及び、クラスタに格納可能な空きディスク量８０６が登録される。空きディスク量８０６は、ヘルスチェック時など適宜のタイミングでクラスタのネームノードに問い合わせて更新されてもよいし、データの削除時及び書き込み時に増減させてもよい。

図９は、ゲートウェイ装置３０に具備されるデータポリシー管理テーブル１２３の一例を示したものである。データポリシー管理テーブル１２３には、例えば、ポリシーを識別するポリシーＩＤ９０２、アプリケーションの種別を示す文字列又は識別番号等のアプリケーション種別９０３、データの複製をいくつ保持するかを示すデータ冗長度９０４、データ読込みの際に多数決によってデータが正しいかどうかを判定するかどうかを示す読込多数決判定情報９０５、データを格納する際にデータ圧縮を適用するかどうかを示すデータ圧縮情報９０６、及び、データを保管する期限を示すデータ保管期限９０７が登録される。あるアプリケーション種別のファイルをデータノードに書き込む際に容量が不足している場合、データ保管期限９０７を超えているファイルを削除して容量を確保し、ファイルを格納することができる。各データは、管理者の操作により入力されるデータに基づいて、データポリシー設定機能部１１７により設定されることができる。

図１０は、ゲートウェイ装置３０に具備されるデータインデクス管理テーブル１２２の一例を示したものである。データインデクス管理テーブル１２２には、例えば、ファイルを識別するデータキー（データＫｅｙ。例えば、ファイルパス及びファイル名から求めたハッシュ値）１００２、ファイルの保持されている１つ又は複数のクラスタのクラスタＩＤ１００３、ファイル名１００４、アプリケーション種別１００５、ファイルのサイズ１００６、及び、ファイルの最終更新日付１００７が登録される。なお、データキー及びファイル名はファイルを識別するファイル識別情報であり、クラスタＩＤ１００３、アプリケーション種別１００５、ファイルのサイズ１００６、及び、ファイルの最終更新日付１００７はファイルに関連するファイル情報である。

図１１は、ゲートウェイ装置３０のメモリ１０６に格納されるクラスタ分散ルール１１０１の一例を示したものである。クラスタ分散ルール１１０１は、ルール種別１１０２と、ルールの使用及び未使用のいずれかを示すフラグ１１０３を含む。ルール種別１０２としては、例えば順次クラスタを選択するラウンドロビン、及び、空きディスク量の多いクラスタを優先して選択するディスク空き優先などを含むことができる。ルール種別１０２はこれらの例に限らず適宜の手法を用いてもよい。使用フラグは設定部（図示せず）により適宜設定を変更できる。

図１２は、ゲートウェイ装置３０のメモリ１０６に格納されるデータリストアルール１２０１の一例を示したものである。データリストアルール１２０１は、ルール種別１２０２と、データリストアを適用するかどうかを判定するための閾値１２０３を含む。本実施例では、異常継続時間によりデータリストアを適用するか否かを判断しており、閾値１２０３の一例として２４時間が記憶される。なお、異常継続時間により判断する以外にも、適宜の適用ルールを定め、ルール種別に登録してもよい。閾値１２０３は、閾値以外にも適宜の判断基準又は条件であってもよい。

図３は、ゲートウェイ装置３０の具備するクライアントＡＰＩ機能部の処理ステップの一例を示したものである。クライアントＡＰＩ機能部１１１は、クライアント１０よりファイルサーバクラスタ４０へのリクエスト情報を取得する（Ｓ３０１）。次に、クライアントＡＰＩ機能部１１１は、データ制御機能部１１４を呼出し、データ制御機能部１１４による処理結果を受け取る（Ｓ３０２）。例えば、ファイル作成結果、ファイル読込結果、ファイル削除結果、又は、ファイル検索結果等を受け取る。データ制御機能部１１４の処理については後述する。また、クライアントＡＰＩ機能部１１１は、クライアント１０に、受け取った処理結果に基づいて、リクエスト情報に対するレスポンス情報を返信する（Ｓ３０３）。

図４（ａ）は、ゲートウェイ装置３０の具備するクラスタ設定機能部の処理ステップの一例を示したものである。クラスタ設定機能部１１２は、管理者の操作により入出力装置１０６からクラスタ情報を入力する（Ｓ４０１）。入力されるクラスタ情報は、例えば、クラスタＩＤ及びネームノードアドレスの組をひとつ又は複数含む。また、クラスタＩＤに対応したディスク容量をさらに含んでもよい。クラスタ設定機能部１１２は、入力したクラスタ情報をクラスタ管理テーブル１２１に格納する（Ｓ４０２）。

図４（ｂ）は、ゲートウェイ装置３０の具備するデータポリシー設定機能部の処理ステップの一例を示したものである。データポリシー設定機能部１１７は、管理者の操作により入出力装置１０６からデータポリシー情報を入力する（Ｓ４０３）。入力されるデータポリシー情報は、例えば、ポリシーＩＤ、アプリケーション種別、データ冗長度、読込多数決判定情報、データ圧縮情報、及び、データ保管期限を含む。データポリシー設定機能部１１７は、入力したデータポリシー情報をデータポリシー管理テーブル１２３に格納する（Ｓ４０４）。

図５は、ゲートウェイ装置３０の具備するヘルスチェック機能部の処理ステップの一例を示したものである。ヘルスチェック機能部１１３は、クラスタ管理テーブル１２１を参照してクラスタのネームノードアドレスを取得し（Ｓ５０１）、各クラスタのネームノードに対して問合せを行う（Ｓ５０２）。例えば、ヘルスチェックパケットを送信する。次に、ヘルスチェック機能部１１３は、問い合わせに対する応答結果に従い、クラスタ管理テーブル１２１に稼動状態（例えば正常か異常か）を更新する（Ｓ５０３）。ヘルスチェック機能部１１３は、データリストア機能部１１５を呼び出す（Ｓ５０４）。ステップＳ５０４でデータリストア機能を呼び出すことにより、ヘルスチェックのタイミングで後述するデータのリストアの要否を判定できるが、ステップＳ５０４は省略してもよい。本機能部１１３の処理は、管理者によって明示的に呼び出される場合と、ＯＳのスケジューラを利用して定期的に呼び出される場合とがある。

図６は、ゲートウェイ装置３０の具備するデータ制御機能部の処理ステップの一例を示したものである。データ制御機能部１１４の処理は、例えばクライアントＡＰＩ機能部１１１がクライアント１０からリクエストを取得したことを契機に実行される。

データ制御機能部１１４は、クライアント１０からのリクエスト種別に応じて以降の処理を振り分ける（Ｓ６０１）。

まず、ファイル作成について説明する。データ制御機能部１１４は、リクエスト種別が＜ファイル作成＞の場合、クラスタ管理テーブル１２１及びデータポリシー管理テーブル１２３を参照してファイルを格納するクラスタを選択し、選択したクラスタのネームノードアドレスを取得する（Ｓ６０２）。例えば、データ制御機能部１１４は、クライアント１０からのリクエストに含まれるアプリケーション種別に基づきデータポリシー管理テーブル１２３を参照し、対応するデータ冗長度９０４を取得する。また、データ制御機能部１１４は、クラスタ管理テーブル１２１を参照し、稼働状態８０４が正常を示すクラスタのうち、データ冗長度に対応する数のクラスタを選択する。クラスタの選択手法は、図１１に示すクラスタ分散ルール１１０１に従う。データ制御機能部１１４は、選択したクラスタのネームノードアドレス８０３を取得する。

データ制御機能部１１４は、取得されたネームノードアドレスに従い、選択されたクラスタのネームノードにファイル作成可否を問合せる（Ｓ６０３）。ネームノードからファイル作成可能の回答を受信した場合は、データ制御機能部１１４は、該当するデータノードにファイル作成を要求する（Ｓ６０４）。なお、データ制御機能部１１４は、適宜のタイミングでファイルをクライアント１０から取得し、データノードに転送する。一方、ネームノードからファイル作成可能の回答を受信した場合以外においては、データ制御機能部１１４は、別のクラスタを選択する。クラスタの選択手法は上述の手法と同様である。ネームノードからファイル作成可能の回答を受信した場合以外とは、例えば、クラスタの容量が不足している等によりネームノードからファイル作成が許容困難の回答を受信した場合や、ネームノードから回答が無い場合がある。

データ制御機能部１１４は、ステップ６０３及び６０４の処理を、データ冗長度ポリシーに適したファイル作成処理が完了するまで繰り返す（Ｓ６０５）。ファイル作成処理が完了したら、データ制御機能部１１４は、データインデクス管理テーブル１２２を更新する（Ｓ６０６）。例えば、データ制御機能部１１４は、ファイル名からデータＫｅｙを求め、データＫｅｙと、ファイルを格納した１つ又は複数のクラスタのクラスタＩＤと、ファイル名と、アプリケーション種別と、ファイルのサイズと、最終更新日時をデータインデクス管理テーブル１２２に記憶する。また、データ制御機能部１１４は、ファイル作成結果をクライアントＡＰＩ機能部１１１に返信する（Ｓ６０７）。ファイル作成結果は、例えば、ファイル作成が完了したこと、及び、ファイルを作成したクラスタ等を含むことができる。ファイル作成結果は、クライアントＡＰＩ１１１経由でクライアント１０に送信される。

また、リクエスト種別が＜ファイル読込＞の場合（Ｓ６０１）、データ制御機能部１１４は、クラスタ管理テーブル１２１及びデータインデクス管理テーブル１２３等を参照し、読込対象のファイルが格納されたクラスタのネームノードアドレスを取得する（Ｓ６１１）。例えば、データ制御機能部１１４は、クライアント１０からのリクエストに含まれるファイル名に基づきデータインデクス管理テーブル１２２を参照し、対応するアプリケーション種別１００５とクラスタＩＤ１００３とを取得する。また、データ制御機能部１１４は、取得したアプリケーション種別に基づき、データポリシー管理テーブル１２３を参照し、対応する読込多数決判定情報９０５を取得する。さらに、データ制御機能部１１４は、取得したクラスタＩＤに基づきクラスタ管理テーブル１２１を参照し、対応するネームノードアドレス８０３を取得する。

データ制御機能部１１４は、取得されたネームノードアドレスに従い、選択されたクラスタのネームノードにファイル読込可否を問合せる（Ｓ６１２）。ネームノードからファイル読込可能の回答を受信した場合は、データ制御機能部１１４は、該当するクラスタのデータノードにファイル読込を要求する（Ｓ６１３）。これにより、データ制御機能部１１４は、データノードからファイルを読み込む。一方、ネームノードからファイル読込可能の回答を受信した場合以外においては、データ制御機能部１１４は、対象のファイルを格納するクラスタのうち別のクラスタを選択し、ステップＳ６１２を繰り返す。例えば、データインデクス管理テーブル１２２を参照して取得したクラスタＩＤのうち、他のひとつが選択される。データ制御機能部１１４は、ステップＳ６１２及びＳ６１３の処理を多数決判定ポリシーに適したファイル読込処理が完了するまで繰り返す（Ｓ６１４）。

多数決判定ポリシーが適用される場合、データ制御機能部１１４は、複数のデータノードからファイルを読み込み、その内容が同一のファイルの数が例えば取得した全数の過半数を得た場合に読込処理を完了と判定する。ファイルの同一性は、ＭＤ５等のハッシュ値を計算し同一かどうかでチェックすることができる。ファイル読込処理が完了したら、データ制御機能部１１４は、ファイル読込結果をクライアントＡＰＩ機能部１１１に返信する（Ｓ６１５）。ファイル読込結果は、例えば読み込んだファイルを含む。ファイル読込結果は、クライアントＡＰＩ１１１経由でクライアント１０に送信される。

また、リクエスト種別が＜ファイル削除＞の場合、データ制御機能部１１４は、クラスタ管理テーブル１２１及びデータインデクス管理テーブル１２２を参照し、削除対象のファイルが格納されたクラスタのネームノードアドレスを取得する（Ｓ６２１）。例えば、データ制御機能部１１４は、クライアント１０からのリクエストに含まれるファイル名に基づきデータインデクス管理テーブル１２２を参照し、対応するクラスタＩＤ１００３を取得する。また、データ制御機能部１１４は、取得したクラスタＩＤに基づきクラスタ管理テーブル１２１を参照し、対応するネームノードアドレス８０３を取得する。

データ制御機能部１１４は、取得されたネームノードアドレスに従い、選択されたクラスタのネームノードにファイル削除可否を問合せる（Ｓ６２２）。ネームノードからファイル削除可能の回答を受信した場合は、データ制御機能部１１４は、該当するデータノードにファイル削除を要求する（Ｓ６２３）。これにより、ファイルが格納されたデータノードからファイルを削除する。一方、ネームノードからファイル削除可能の回答を受信した場合以外においては、データ制御機能部１１４は、別のクラスタを選択する。データ制御機能部１１４は、ステップＳ６２２及びＳ６２３を、データを保持しているノードからファイル削除処理が完了するまで繰り返す（Ｓ６２４）。ファイル削除処理が完了したら、データ制御機能部１１４は、データインデクス管理テーブルを更新する（Ｓ６２５）。例えば、対象のファイル名のエントリを削除する。また、データ制御機能部１１４は、ファイル削除結果を返却する（Ｓ６２６）。ファイル削除結果は、例えば、ファイルが正しく削除されたことを示す情報を含む。ファイルが削除できなかったクラスタがある場合は、そのクラスタの識別情報をファイル削除結果に含めてもよい。ファイル削除結果は、クライアントＡＰＩ１１１経由でクライアント１０に送信される。

また、リクエスト種別が＜ファイル検索＞の場合、データ制御機能部１１４は、リクエスト情報に含まれる検索条件によりデータインデクス管理テーブル１２２を検索する（Ｓ６３１）。検索条件としては、例えば、ファイル名の指定、サイズの指定、更新日時の範囲指定等があるが、これら以外でもよい。例えば検索条件がファイル名の指定の場合、データ制御機能部１１４は、リクエスト情報に含まれるファイル名に基づきデータインデクス管理テーブル１２２を参照して該当するエントリの各情報（ファイルの識別情報及び上述のファイル情報）を取得する。そして、データ制御機能部１１４は、ファイル検索結果をクライアントＡＰＩ機能部１１１に返信する（Ｓ６３２）。ファイル検索結果は、例えばデータインデクス管理テーブル１２２から取得した該当エントリの各情報を含む。ファイル検索結果は、クライアントＡＰＩ１１１経由でクライアント１０に送信される。

図７は、ゲートウェイ装置３０の具備するデータリストア機能部の処理ステップの一例を示したものである。データリストア機能部１１５は、クラスタ管理テーブル１２１を参照し（Ｓ７０１）、各クラスタについて、稼動状態として「異常」が格納され、状態変更日時からの経過時間（異常継続時間）が、図１２に示すデータリストアルールに格納された閾値を超過しているか否かを判定する（Ｓ７０２）。超過しているクラスタ（以下、異常継続クラスタと称する）がある場合、データリストア機能部１１５は、データ制御機能部１１４を呼出して、ポリシーに適したファイル作成処理を実行する（Ｓ７０３）。例えば、該当するクラスタに格納されたファイルのデータ冗長度を確保するため、異常継続クラスタ以外のクラスタ等から読み出して、他のクラスタへ格納する。

具体的には、データリストア機能部１１５は、データインデクス管理テーブル１２２のクラスタＩＤを参照して、異常継続クラスタ（第１ファイルサーバクラスタ）のクラスタＩＤが登録されているエントリを検索する。データリストア機能部１１５は、該当するエントリのアプリケーション種別１００６に基づき、データポリシー管理テーブル１２３を参照し、対応するデータ冗長度を取得する。データ冗長度が複数の場合、異常継続クラスタが異常状態であることにより冗長度が下がっていることになる。従って、データリストア機能部１１５は、データインデクス管理テーブル１２２の該当エントリを再度参照し、異常継続クラスタ以外のクラスタＩＤを特定する。特定されたクラスタＩＤが示すクラスタ（第２ファイルサーバクラスタ）から、図６に示すファイル読込処理と同様にしてファイルを読み込む。なお、データリストア機能部１１５は他の適宜の装置からファイルを読み込んでもよい。また、データリストア機能部１１５は、読み込んだファイルを、図６に示すファイル作成処理と同様にして、データインデクス管理テーブル１２２の該当エントリのクラスタＩＤ１００３とは別のクラスタ（第３ファイルサーバクラスタ）に書き込む。

なお、データリストア機能部１１６の処理は、ヘルスチェック機能部１１３により呼び出される他、他の適宜のトリガにより実行されてもよいし、定期的に実行されてもよい。

図１３は、クライアント１０からゲートウェイ装置３０がファイル作成ＡＰＩリクエストを受信し、クラスタ＃１００１及び＃１００３にファイルを作成する処理フロー１３０１の一例を示したものである。この例においては、クラスタ＃１００２のネームノードに障害が発生している。ファイル作成ＡＰＩリクエストを受信した後、ゲートウェイ装置３０においては以下の処理が実行される。ファイル作成ＡＰＩリクエストの例を、図１７に示す（ｈｔｔｐ：／／ｇａｔｅｗａｙ１／ｗｅｂｈｄｆｓ／ｖ１／ｕｓｅｒ／ｙａｍａｄａ／ｆｉｌｅａｂｃ００１．ｔｘｔ？ｏｐ＝ｃｒｅａｔｅ＆ｔｙｐｅ＝ＡＰ２）。ファイル作成ＡＰＩリクエストは、例えば、ファイル名と、リクエスト種別と、アプリケーション種別とを含む。

まず、ゲートウェイ装置３０は、図８に示すクラスタ管理テーブル１２１を参照し、クラスタ＃１００２に障害が発生していることを取得する。次に、ゲートウェイ装置３０は、図９に示すデータポリシー管理テーブル１２３を参照し、アプリケーション種別がＡＰ２の場合に、データの多重度（データ冗長度）が２であることを取得する。次に、ゲートウェイ装置３により、例えば正常なクラスタ＃１００１及び＃１００３が候補として選択され、各クラスタのネームノードに対して、ファイル作成要求がそれぞれ送られる。ゲートウェイ装置３０は、ネームノードからファイル作成応答：可（ａｃｃｅｐｔａｂｌｅ）を受信した場合、指定されたデータノードにファイルを書き込む。ゲートウェイ装置３０は、２つのデータノードへの書き込みが成功すると（ファイル書込の完了通知を受信すると）、データインデクス管理テーブルの内容を更新し、クライアントに対してファイル作成完了を応答する。

図１４は、クライアント１０からゲートウェイ装置３０がファイル読込ＡＰＩリクエストを受信し、クラスタ＃１００１又は＃１００３からファイルを読み込む処理フロー１４０１の一例を示したものである。この例においては、クラスタ＃１００２のネームノードに障害が発生している。ファイル読込ＡＰＩリクエストを受信した後、ゲートウェイ装置３０においては以下の処理が実行される。ファイル読込ＡＰＩリクエストの例を、図１７に示す
（ｈｔｔｐ：／／ｇａｔｅｗａｙ１／ｗｅｂｈｄｆｓ／ｖ１／ｕｓｅｒ／ｙａｍａｄａ／ｆｉｌｅａｂｃ００１．ｔｘｔ？ｏｐ＝ｏｐｅｎ）。ファイル読込ＡＰＩリクエストは、例えば、読込対象のファイル名と、リクエスト種別とを含む。

まず、ゲートウェイ装置３０は、図８に示すクラスタ管理テーブル１２１を参照し、クラスタ＃１００２に障害が発生していることを取得する。次に、ゲートウェイ装置３０は、図１０に示すデータインデクス管理テーブル１２２を参照し、読込対象のファイルがクラスタ＃１００１及び＃１００３に格納されていることを取得する。ゲートウェイ装置３０は、クラスタ＃１００１のネームノードにファイル読込要求を送り、その応答が「可」であった場合、該当するデータノードに対するファイル読込を実行し、ファイルを取得する。また、ゲートウェイ装置３０は、読み込んだファイルをクライアント１０に転送して読込完了する。一方、ネームノード＃１００１の応答が「許容困難」（ｎｏｔ ａｃｃｅｐｔａｂｌｅ）であった場合は、ゲートウェイ装置３０は、ネームノード＃１００３にファイル読込要求を送り、その応答が「可」であった場合、該当するデータノードに対するファイル読込を実行し、ファイルを取得する。ネームノード＃１００３の応答が「許容困難」であった場合、ゲートウェイ装置３０は、クライアント１０にファイル読込失敗を応答する。

図１５は、クライアント１０からゲートウェイ装置３０がファイル削除ＡＰＩリクエストを受信し、クラスタ４０＃１００１及び＃１００３にファイルを削除する処理フロー１５０１の一例を示したものである。この例においては、クラスタ＃１００２のネームノードに障害が発生している。ファイル削除ＡＰＩリクエストを受信した後、ゲートウェイ装置３０においては以下の処理が実行される。ファイル削除ＡＰＩリクエストの例を、図１７に示す（ｈｔｔｐ：／／ｇａｔｅｗａｙ１／ｗｅｂｈｄｆｓ／ｖ１／ｕｓｅｒ／ｙａｍａｄａ／ｆｉｌｅａｂｃ００１．ｔｘｔ？ｏｐ＝ｄｅｌｅｔｅ）。ファイル削除ＡＰＩリクエストは、例えば、削除対象のファイル名と、リクエスト種別とを含む。

まず、ゲートウェイ装置３０は、図８に示すクラスタ管理テーブル１２１を参照し、クラスタ＃１００２に障害が発生していることを取得する。次に、ゲートウェイ装置３０は、図１０に示すデータインデクス管理テーブル１２２を参照し、ファイルがクラスタ＃１００１及び＃１００３に格納されていることを取得する。

ゲートウェイ装置３０は、クラスタ＃１００１及び＃１００３のネームノードにファイル削除要求を送り、その応答が「可」であった場合、該当するデータノードにファイル削除を実行し、ファイルを削除する。また、ゲートウェイ装置３０は、クライアント１０にファイル削除完了を応答する。

図１６は、クライアント１０からゲートウェイ装置３０がファイル検索ＡＰＩリクエストを受信し、検索条件に適合するファイル一覧を探す処理フロー１６０１の一例を示したものである。ファイル検索ＡＰＩリクエストの例を、図１７に示す（ｈｔｔｐ：／／ｇａｔｅｗａｙ１／ｗｅｂｈｄｆｓ／ｖ１／ｕｓｅｒ／ｙａｍａｄａ？ｏｐ＝ｆｉｎｄ＆ｎａｍｅ＝＊ａｂｃ＊＆ｓｉｚｅ＞＝１Ｍ）。ファイル検索ＡＰＩリクエストは、例えばリクエスト種別と、検索条件とを含む。図１７の例は、検索条件として、ファイル名にａｂｃを含み、サイズが１ＭＢ以上のファイルを検索する条件を含む。

ゲートウェイ装置３０は、ファイル検索ＡＰＩリクエストを受信した後、まず、図１０に示すデータインデクス管理テーブル１２２を検索し、条件に適合するファイル情報一覧を取得する。また、ゲートウェイ装置３０は、クライアント１０にファイル検索完了を応答する。

図２２は、本実施例のゲートウェイ装置の概略シーケンス図である。
ゲートウェイ装置３０のヘルスチェック機能部１１３は、ファイルサーバクラスタ４０の稼動状態を監視する（Ｓ２２０１）。また、ゲートウェイ装置３０のデータ制御機能部１１４は、クライアント装置から分散ファイルシステムへのリクエストを受信する（Ｓ２２０２）。ゲートウェイ装置３０のデータ制御機能部１１４は、正常に稼働中のファイルサーバクラスタ４０の中からひとつ又は複数を選択する（Ｓ２２０３）。また、ゲートウェイ装置３０のデータ制御機能部１１４は、リクエストを、選択したファイルサーバクラスタ４０へ振り分けて送信する（Ｓ２２０４）。

本実施例によると、複数のクライアント端末と、サーバとローカルディスクで構成される分散ファイルシステムが大量データをやりとりするシステムにおいて、システム全体の可用性を向上させることができる。

また、本実施例によれば、分散ファイルシステムに対するリクエストに対し、アプリケーション拡張ゲートウェイ装置が、アプリケーションの要求するレベルに沿って、データを処理する適切なサーバを選択し、データの分散処理を実施することが可能である。また、アプリケーションの要求するレベルに沿って、データ、及びデータのメタ情報を複数のサーバで分散管理することにより、サーバやローカルディスクの障害発生時に、サービスを停止せずにデータ処理を実行することが可能である。

さらに、本実施例によれば、分散ファイルシステムのサーバソフトウェアに変更を加えることなく、アプリケーション拡張ゲートウェイ装置を導入することが可能である。さらにゲートウェイ装置においては、アプリケーション種類に応じてデータの管理ポリシーを柔軟に設定し実行することや、ファイル検索機能部などの付加機能部を追加することが可能である。

また、本実施例によれば、高性能なサーバを必要とせず、大量データを管理するソフトウェアを必要とせず、導入が容易である。その一方で、おろそかになる信頼性確保のため、複数のサーバで同じ処理を並列実行させて、データを冗長化することにより高信頼性を維持することが可能となる。

（実施例２）
実施例１では、複数のファイルサーバクラスタが予め構築されており、データの分散化をそのまま行って構わない場合について説明した。実施例２では、初期の段階ではファイルサーバクラスタが１つしかなく、分散化されていないデータが存在する場合について移行方法を説明する。

データ移行した後の部分は実施例１と同様である。そのため、本実施例では実施例１との相違点を中心に説明する。

図１８は、実施例２におけるシステムの全体構成の一例を示したものである。初期の段階ではクラスタ＃１００１（第４ファイルサーバクラスタ）にデータが格納されており、新たに追加されたクラスタ＃１００２及び＃１００３（第５ファイルサーバクラスタ）に＃１００１のデータの一部が複製されることにより、複数のクラスタによりデータ冗長化が行われることを示している。新たに追加されたクラスタ＃１００２及び＃１００３には通常、ファイルが格納されていないが、何らかのファイルが格納されていても構わない。

図１９は、実施例２におけるゲートウェイ装置の構成の一例を示している。実施例２におけるゲートウェイ装置３０は、クラスタ再構成機能部１１６をさらに備え、クラスタ再構成機能部１１６によりデータの移行処理が行われる。

図２１は、アプリケーション拡張ゲートウェイ装置が保持するデータ再構成ルールを管理するテーブルの構成例を示す図である。データ再構成ルールは予め定められ、メモリ１０５に格納される。例えば、データ再構成ルールは、ファイルの移行元クラスタＩＤ２１０２と、１つ又は複数の移行先クラスタＩＤ２１０３と、データポリシーＩＤ２１０４を含む。データポリシーＩＤ２１０４は、図９に示すデータポリシー管理テーブル１２２に格納されたポリシーＩＤ９０２に対応する。この例では、データポリシー管理テーブル１２２に格納された複数のポリシーのうちのいずれかを選択的に用いており、既存のポリシーから選択することで設定を簡素化できる。なお、新たなポリシーを設定してもよい。

図２０は、ゲートウェイ装置３０が具備するクラスタ再構成機能部１１６の処理ステップの一例を示したものである。クラスタ再構成機能部１１６は、図２１に示すデータ再構成ルール２１０１、及び、図８に示すクラスタ管理テーブル１２１を参照し（Ｓ２００１）、移行元のクラスタ＃１００１からデータファイルの一覧、データファイルを取得する（Ｓ２００２）。次に、クラスタ再構成機能部１１６は、移行先クラスタ＃１００２及び＃１００３に対して、データ制御機能部１１４を呼び出すことにより実施例１と同様にファイル作成処理を実行する（Ｓ２００３）。この際に、図２１のデータポリシーＩＤ＝２のポリシーが適用される。ここでは、データ冗長度が２であるため、移行元のクラスタ＃１００１のデータファイルが複製されて、移行先のクラスタ＃１００２及び＃１００３に適宜振り分けられる。また、クラスタ再構成機能部１１６は、移行したファイルについてデータインデクス管理テーブル１２２を更新する（Ｓ２００４）。更新の手法は、実施例１におけるファイル書込処理の場合と同様である。

本実施例によると、ゲートウェイ装置により、１つのファイルサーバクラスタしかないシステムから分散化されたシステムへ移行できる。また、移行後は、実施例１におけるゲートウェイ装置による処理を適用できる。なお、上述の例では、１つのファイルサーバクラスタしかない場合を説明したが、複数のファイルサーバクラスタがあるシステムに新たなファイルサーバクラスタを設ける場合にも適用できる。

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

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１０ クライアント
２０ ネットワーク
３０ アプリケーション拡張ゲートウェイ装置
４０ ファイルサーバクラスタ
５０ ネームノード
６０ データノード
１１１ クライアントＡＰＩ機能部
１１２ クラスタ設定機能部
１１３ ヘルスチェック機能部
１１４ データ制御機能部
１１５ データリストア機能部
１１６ クラスタ再構成機能部
１１７ データポリシー設定機能部
１２１ クラスタ管理テーブル
１２２ データインデクス管理テーブル
１２３ データポリシー管理テーブル

Claims (14)

1. ファイル格納、ファイル読込及びファイル削除のいずれかを含むリクエストを送信するクライアント装置と、該リクエストに応じたファイル処理を行う複数のファイルサーバクラスタを有する分散ファイルシステムとの間でリクエストを仲介するゲートウェイ装置であって、
   前記ファイルサーバクラスタの稼動状態を監視するヘルスチェック機能部と、
   前記クライアント装置から前記分散ファイルシステムへのリクエストを受信し、正常に稼働中のファイルサーバクラスタの中からひとつ又は複数を選択して該リクエストを選択したファイルサーバクラスタへ振り分けるデータ制御機能部と
   を有するゲートウェイ装置。
2. データ冗長度が設定されたデータポリシー記憶領域
   をさらに備え、
   前記データ制御機能部は、ファイル格納のリクエストを受信すると、データ冗長度に応じた数の複数のファイルサーバクラスタを選択し、該ファイルサーバクラスタのそれぞれに前記リクエストを送信して各ファイルサーバクラスタにファイルを格納する請求項１に記載のゲートウェイ装置。
3. 前記データポリシー記憶領域は、アプリケーション種別毎にデータ冗長度が設定され、
   前記ファイル格納のリクエストは、格納するファイルのアプリケーション種別を含み、
   前記データ制御機能部は、前記データポリシー記憶領域を参照して、前記ファイル格納のリクエストに含まれるアプリケーション種別に対応するデータ冗長度を特定する請求項２に記載のゲートウェイ装置。
4. 操作者の操作に従い、アプリケーション種別に対応するデータ冗長度を前記データ記憶領域に設定するデータポリシー設定部
   をさらに備える請求項３に記載のゲートウェイ装置。
5. ファイルの識別情報と、該ファイルを格納した１つ又は複数の前記ファイルサーバクラスタの識別情報とを少なくとも含むデータインデクスを記憶するデータインデクス記憶領域
   をさらに備え、
   前記データ制御機能部は、読込対象のファイルの識別情報を含むファイル読込のリクエストを受信すると、前記データインデクス記憶領域を参照して、読込対象のファイルが記憶された前記ファイルサーバクラスタを特定し、特定された前記ファイルサーバクラスタの１つ又は複数に該リスエストを送信して対象のファイルを読み込む請求項１に記載のゲートウェイ装置。
6. 読込多数決判定の要否を示す判定情報が設定されたデータポリシー記憶領域
   をさらに備え、
   前記データ制御機能部は、ファイル読込のリクエストを受信すると、前記データポリシー記憶領域の判定情報が読込多数決判定することを示す場合、特定された前記ファイルサーバクラスタの複数に該リスエストを送信し、複数のファイルサーバクラスタから取得したファイルの同一性をチェックして同一多数により読込完了と判定する請求項５に記載のゲートウェイ装置。
7. ファイルの識別情報と、該ファイルを格納した１つ又は複数の前記ファイルサーバクラスタの識別情報とを少なくとも含むデータインデクスを記憶するデータインデクス記憶領域
   をさらに備え、
   前記データ制御機能部は、削除対象のファイルの識別情報を含むファイル削除のリクエストを受信すると、前記データインデクス記憶領域を参照して、削除対象のファイルが記憶されたファイルサーバクラスタを特定し、特定されたファイルサーバクラスタの１つ又は複数に該リスエストを送信して対象のファイルを削除する請求項１に記載のゲートウェイ装置。
8. ファイルの識別情報と、該ファイルのサイズ、アプリケーション種別及び更新日時の少なくともいずれかを含むファイル情報とを含むデータインデクスを記憶するデータインデクス記憶領域
   をさらに備え、
   前記データ制御機能部は、前記クライアント装置から検索条件を含むファイル検索のリクエストを受信すると、自装置の前記データインデクス記憶領域を検索して条件に合致するファイルのファイル識別情報及び／又はファイル情報を前記クライアント装置に返信する請求項１に記載のゲートウェイ装置。
9. 前記データ制御機能部は、前記ファイル格納のリクエストの受信により各ファイルサーバクラスタにファイルを格納すると、前記データインデクス記憶領域に、ファイルの識別情報と、格納した各ファイルサーバクラスタの識別情報と、ファイルのサイズと、アプリケーション種別と、更新日時とを記憶する請求項８に記載のゲートウェイ装置。
10. 前記ヘルスチェック機能部により異常状態と判定された継続時間が予め定められた閾値を超過した第１ファイルサーバクラスタについて、該第１ファイルサーバクラスタに格納されているファイルと同じファイルを第２ファイルサーバクラスタ又は他の装置から取得して複製し、第３のファイルサーバクラスタへ格納することで、第１ファイルサーバクラスタに格納されているファイルのデータ冗長度を満たすデータリストア機能部
    をさらに備える請求項１乃至９のいずれかに記載のゲートウェイ装置。
11. 前記分散ファイルシステムが、ファイルが既に格納された第４ファイルサーバクラスタと、ファイルが格納されていない又は新たに設置される１つ又は複数の第５ファイルサーバクラスタとを含み、
    前記ゲートウェイ装置は、前記第４ファイルサーバクラスタのファイル及びメタデータを取得して複製し、前記第５ファイルサーバクラスタのいずれかへ格納するクラスタ再構成機能部
    をさらに備える請求項１乃至１０のいずれかに記載のゲートウェイ装置。
12. 前記クラスタ再構成機能部は、第４ファイルサーバクラスタから取得したファイルのデータ冗長度に応じて該ファイルを複製し、前記第５ファイルサーバクラスタに格納する請求項１１に記載のゲートウェイ装置。
13. リクエストに応じてファイル格納、ファイル読込及びファイル削除のいずれかを行う複数のファイルサーバクラスタを有する分散ファイルシステムと、
    ファイル格納、ファイル読込及びファイル削除のいずれかを含むリクエストを送信するクライアント装置と前記分散ファイルシステムとの間でリクエストを仲介するゲートウェイ装置と
    を備え、
    前記ゲートウェイ装置は、
    前記ファイルサーバクラスタの稼動状態を監視するヘルスチェック機能部と、
    前記クライアント装置から前記分散ファイルシステムへのリクエストを受信し、正常に稼働中のファイルサーバクラスタの中からひとつ又は複数を選択して該リクエストを選択したファイルサーバクラスタへ振り分けるデータ制御機能部と
    を有するファイルサーバシステム。
14. リクエストに応じてファイル格納、ファイル読込及びファイル削除のいずれかを行う複数のファイルサーバクラスタを有する分散ファイルシステムと、ファイル格納、ファイル読込及びファイル削除のいずれかを含むリクエストを送信するクライアント装置と前記分散ファイルシステムとの間でリクエストを仲介するゲートウェイ装置とを備えたファイルサーバシステムにおけるファイル分散方法であって、
    前記ゲートウェイ装置が、
    前記ファイルサーバクラスタの稼動状態を監視し、
    前記クライアント装置から前記分散ファイルシステムへのリクエストを受信し、正常に稼働中のファイルサーバクラスタの中からひとつ又は複数を選択して該リクエストを選択したファイルサーバクラスタへ振り分ける前記ファイル分散方法。

Images