(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-04-27
(45)【発行日】2023-05-10
(54)【発明の名称】分散システムでのメタデータルーティング
(51)【国際特許分類】
G06F 16/27 20190101AFI20230428BHJP
G06F 16/182 20190101ALI20230428BHJP
【ＦＩ】
G06F16/27
G06F16/182
【請求項の数】
15
(21)【出願番号】P 2021549412
(86)(22)【出願日】2019-03-04
(65)【公表番号】
(43)【公表日】2022-04-06
(86)【国際出願番号】 US2019020502
(87)【国際公開番号】W WO2020180291
(87)【国際公開日】2020-09-10
【審査請求日】2021-08-20
(73)【特許権者】
【識別番号】520155228
【氏名又は名称】ヒタチ ヴァンタラ エルエルシー
(74)【代理人】
【識別番号】110000279
【氏名又は名称】弁理士法人ウィルフォート国際特許事務所
(72)【発明者】
【氏名】トッド， アンドリュー
(72)【発明者】
【氏名】ウォラー， ワルター
【審査官】齊藤 貴孝
(56)【参考文献】
【文献】米国特許出願公開第２０１７／０１３９９１０（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１１／０１７９００８（ＵＳ，Ａ１）
【文献】特開２０１８－０４９６４４（ＪＰ，Ａ）
【文献】国際公開第２００４／０５５６７５（ＷＯ，Ａ１）
【文献】特表２０１５－５０４２１８（ＪＰ，Ａ）
【文献】特開２０１６－０２４６１２（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １６／００－１６／９５８
(57)【特許請求の範囲】
【請求項1】
システムであって、複数のメタデータノードと通信することができる第１計算装置を備え、各メタデータノードは前記複数のメタデータノードにわたりメタデータデータベースを分散するために前記メタデータデータベースの分割に基づいて前記メタデータデータベースの一部を維持し、
前記第１計算装置は、実行可能な命令によって動作を実行するように構成され、前記動作は：
前記第１計算装置により、前記メタデータデータベースの分割を指示するパーティションマッピング情報を第２計算装置から受信すること；
前記第１計算装置により、第１メタデータのための前記メタデータデータベースに対してデータベース動作を実行することを決定することであって、前記第１メタデータはキー情報に関連付けられる、判定すること；
前記第１計算装置により、前記キー情報に対応する前記メタデータデータベースのパーティションを維持するように指示された前記複数のメタデータノードの第１メタデータノードを決定するために前記パーティションマッピング情報へアクセスすること；及び
前記第１計算装置により、前記パーティションマッピング情報に基づいて、前記第１メタデータの前記データベース動作を実行するための要求を前記第１メタデータノードへ送信すること、
とを含み、
前記複数のメタデータノードにわたって前記メタデータデータベースを分散するための前記メタデータデータベースの分割は、前記メタデータデータベースの複数のパーティションのそれぞれである第１パーティションを複数の前記メタデータノードへ割り当てることを含み、
前記第１メタデータノードは、前記第１メタデータノードにおいて前記メタデータデータベースの割り当てられた前記第１パーティションを維持することに基づいて、メタデータデータベース要求に応答するように構成されたリーダノードであり；
少なくとも１つの第２メタデータノードは、前記第１パーティションの複製を維持し、前記メタデータデータベースの前記第１パーティションに対する更新を前記第１メタデータノードから受信し、前記第１パーティションの前記複製へ更新を適用するように構成されたフォロワノードであり、
複数の前記第１パーティションに対して、異なる前記第１メタデータノードが割り当てられている、システム。
【請求項2】
請求項１に記載のシステムにおいて、
一の前記第１パーティションに対する前記リーダノードが、他の前記第１パーティションに対するフォロワノードである、システム。
【請求項3】
請求項１に記載のシステムにおいて、前記パーティションマッピング情報を受信する前記動作は、
前記パーティションマッピング情報の要求を前記第２計算装置へ送信すること；
前記要求に応答して前記第２計算装置から前記パーティションマッピング情報を受信すること；及び
前記受信されたパーティションマッピング情報を前記第１計算装置のコンピュータ可読媒体上に格納することを含む、システム。
【請求項4】
請求項３に記載のシステムにおいて、前記第２計算装置において、前記第２計算装置における前記パーティションマッピング情報の変化に応答して前記第１計算装置における前記パーティションマッピング情報に対する更新を受信するための要求を登録すること；
前記第１計算装置において、前記パーティションマッピング情報に対する前記更新を受信すること；及び
前記第１計算装置により、前記受信された更新に基づいて、前記第１計算装置の前記コンピュータ可読媒体上に格納されている前記パーティションマッピング情報を更新すること、をさらに含む、システム。
【請求項5】
請求項１に記載のシステムにおいて、前記動作は、前記第１メタデータノードへ送信される前記要求に対する応答を受信しないことに基づいて、及び前記第２メタデータノードが前記第１パーティションの前記複製を維持していることを示す前記パーティションマッピング情報に基づいて、前記第１計算装置により、前記データベース動作を実行するための前記要求を前記第２メタデータノードへ送信することをさらに含む、システム。
【請求項6】
請求項１に記載のシステムにおいて、前記第２メタデータノードは、前記リーダノードとして前記第１メタデータノードにとって代わり、前記メタデータデータベースの前記第１パーティションへアクセスするためのメタデータデータベースアクセス要求に応答するように前記第２メタデータノードを構成し、前記動作は、
前記第１計算装置により、前記キー情報に関連する前記第１メタデータに対する前記要求に応答して、前記第１メタデータノードが前記要求に応答しないというしるしを受信することであって、前記しるしを受信することは、前記第２メタデータノードが今や前記第１パーティションに対するメタデータデータベース要求に応答するように構成された前記リーダノードであるという通知を受信することをさらに含む、受信すること；及び
前記第１計算装置により、前記第２メタデータノードが今や前記リーダノードであるという通知に基づいて、前記キー情報に関連する前記第１メタデータについての前記要求を前記第２メタデータノードへ送信すること、をさらに含む、システム。
【請求項7】
請求項１に記載のシステムにおいて、前記第１メタデータノードは、前記第２メタデータノードと、前記メタデータデータベースの前記第１パーティションの複製も維持する少なくとも１つの他のメタデータノードとに定期的にメッセージを送信するように構成され；
前記メッセージを閾値期間の間送信することの前記第１メタデータノードの失敗に続いて、第２メタデータノードは、前記少なくとも１つの他のノードからの合意に基づいて、前記リーダノードとして前記第１メタデータノードにとって代わり、前記第２メタデータノードは、前記メタデータデータベースの前記第１パーティションへアクセスするためのメタデータデータベースアクセス要求に応答するように構成されている、システム。
【請求項8】
請求項１に記載のシステムにおいて、前記第１計算装置により、第１メタデータの前記メタデータデータベースに対してデータベース動作を実行することを判定することは、ユーザウェブアプリケーションを介したユーザ装置からの要求；又はユーザウェブアプリケーションを介した管理者装置からの要求の少なくとも１つを受信することに応答する、システム。
【請求項9】
請求項１に記載のシステムにおいて、前記第１計算装置により、第１メタデータの前記メタデータデータベースに対してデータベース動作を実行することを判定することは、更新キューから決定された１又は複数の非同期格納関連動作を行うための非同期管理プログラムの動作に応答する、システム。
【請求項10】
請求項１に記載のシステムにおいて、第１計算装置は、前記パーティションマッピング情報の少なくとも一部をキー空間ツリーデータ構造として格納し、
前記複数のメタデータノードの前記第１メタデータノードを判定するために前記パーティションマッピング情報にアクセスする前記動作は、前記キー情報に対応する前記第１パーティションを判定するために前記キー空間ツリーデータ構造を横断することをさらに含む、システム。
【請求項11】
請求項１に記載のシステムにおいて、前記第１メタデータノードから応答を受信することに基づいて、遠隔ストレージシステムからネットワーク上でデータを取得するためにメタデータ情報を別の計算装置へ送信することをさらに含む、システム。
【請求項12】
方法であって、第１計算装置により、メタデータデータベースのパーティションを示すパーティションマッピング情報を第２計算装置から受信することであって、前記第１計算装置は複数のメタデータノードと通信することができ、各メタデータノードは前記複数のメタデータノードにわたりメタデータデータベースを分散するために前記メタデータデータベースの分割に基づいてメタデータデータベースの一部を維持する、受信すること；
前記第１計算装置により、少なくともキー情報に基づいて、前記メタデータデータベースへ要求を送信することを判定すること；
前記第１計算装置により、前記パーティションマッピング情報に基づいて、前記キー情報に対応する前記メタデータデータベースのパーティションを維持するように指示された前記複数のメタデータノードの内の第１メタデータノードを判定すること；及び
前記第１計算装置により、前記パーティションマッピング情報に基づいて、データベース動作を実行するための要求を前記第１メタデータノードへ送信すること、を含み、
前記複数のメタデータノードにわたって前記メタデータデータベースを分散するための前記メタデータデータベースの分割は、前記メタデータデータベースの複数のパーティションのそれぞれである第１パーティションを複数の前記メタデータノードへ割り当てることを含み、
前記第１メタデータノードは、前記第１メタデータノードにおいて前記メタデータデータベースの割り当てられた前記第１パーティションを維持することに基づいて、メタデータデータベース要求に応答するように構成されたリーダノードであり；
少なくとも１つの第２メタデータノードは、前記第１パーティションの複製を維持し、前記メタデータデータベースの前記第１パーティションに対する更新を前記第１メタデータノードから受信し、前記第１パーティションの前記複製へ更新を適用するように構成されたフォロワノードであり、
複数の前記第１パーティションに対して、異なる前記第１メタデータノードが割り当てられている、方法。
【請求項13】
請求項１２に記載の方法において、前記パーティションマッピング情報の要求を前記第２計算装置へ送信すること；
前記要求に応答して前記第２計算装置から前記パーティションマッピング情報を受信すること；
前記受信されたパーティションマッピング情報を前記第１計算装置のコンピュータ可読媒体上に格納すること；
前記第２計算装置における前記パーティションマッピング情報の変化に応答して、前記第２計算装置において、前記第１計算装置における前記パーティションマッピング情報に対する更新を受信するための要求を登録すること；
前記第１計算装置において、前記パーティションマッピング情報に対する前記更新を受信すること；及び
前記第１計算装置により、前記受信された更新に基づいて、前記第１計算装置の前記コンピュータ可読媒体上に格納される前記パーティションマッピング情報を更新すること、をさらに含む、方法。
【請求項14】
１又は複数のプロセッサにより実行されるといくつかの動作を行うように前記１又は複数のプロセッサを構成する命令を格納する１又は複数の非一時的コンピュータ可読媒体であって、前記動作は、第１計算装置により、メタデータデータベースのパーティションを示すパーティションマッピング情報を第２計算装置から受信することであって、前記第１計算装置は複数のメタデータノードと通信することができ、各メタデータノードは前記複数のメタデータノードにわたりメタデータデータベースを分散するために前記メタデータデータベースの分割に基づいて、前記メタデータデータベースの一部を維持する、受信すること；
前記第１計算装置により、少なくともキー情報に基づいて、要求を前記メタデータデータベースへ送信することを判定すること；
前記第１計算装置により、前記キー情報に対応する前記メタデータデータベースのパーティションを維持するために指示された前記複数のメタデータノードの第１メタデータノードを前記パーティションマッピング情報に基づいて判定すること；及び
前記第１計算装置により、前記パーティションマッピング情報に基づいて、データベース動作を実行するための要求を前記第１メタデータノードへ送信すること、を含み、
前記複数のメタデータノードにわたって前記メタデータデータベースを分散するための前記メタデータデータベースの分割は、前記メタデータデータベースの複数のパーティションのそれぞれである第１パーティションを複数の前記メタデータノードへ割り当てることを含み、
前記第１メタデータノードは、前記第１メタデータノードにおいて前記メタデータデータベースの割り当てられた前記第１パーティションを維持することに基づいて、メタデータデータベース要求に応答するように構成されたリーダノードであり；
少なくとも１つの第２メタデータノードは、前記第１パーティションの複製を維持し、前記メタデータデータベースの前記第１パーティションに対する更新を前記第１メタデータノードから受信し、前記第１パーティションの前記複製へ更新を適用するように構成されたフォロワノードであり、
複数の前記第１パーティションに対して、異なる前記第１メタデータノードが割り当てられている、非一時的コンピュータ可読媒体。
【請求項15】
請求項１４に記載の１又は複数の非一時的コンピュータ可読媒体において、前記動作は、
前記パーティションマッピング情報の要求を前記第２計算装置へ送信すること；
前記要求に応答して前記第２計算装置から前記パーティションマッピング情報を受信すること；
前記受信されたパーティションマッピング情報を前記第１計算装置のコンピュータ可読媒体上に格納すること；
前記第２計算装置において、前記第２計算装置における前記パーティションマッピング情報の変化に応答して前記第１計算装置における前記パーティションマッピング情報に対する更新を受信するための要求を登録すること；
前記第１計算装置において、前記パーティションマッピング情報に対する前記更新を受信すること；及び
前記第１計算装置により、前記受信された更新に基づいて、前記第１計算装置の前記コンピュータ可読媒体上に格納される前記パーティションマッピング情報を更新すること、をさらに含む、非一時的コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示はデータストレージの技術分野に関する。
【背景技術】
【0002】
多分割データベースは「ノード」とも呼ばれる複数の計算装置の間でメタデータサービスを分割することによりスケーラビリティを提供し得る。例えば、メタデータの高可用性及び障害耐性は、複数のノードにわたってメタデータを複製することにより提供され得る。しかし、メタデータにアクセスしようとするクライアントは、見つけようとしているメタデータに対してどのノードが責任があるかを決定することに困難を感じ得る。いくつかのケースでは、これは、アクセスすべき正しいノードを発見するための過剰な数のネットワーク要求を生じ得、例えばネットワーク輻輳を引き起こし、システムスケーラビリティを制限し、システム再構成の柔軟性に影響を与える等する。
【発明の概要】
【課題を解決するための手段】
【0003】
いくつかの実施形態は、複数のメタデータノードと通信することができる第１計算装置を含む。それぞれのメタデータノードは、複数のメタデータノードにわたりメタデータデータベースを分配するために、メタデータデータベースの分割に基づいてメタデータデータベースの一部を維持する。いくつかの例では、第１計算装置は、メタデータデータベースのパーティションを示すパーティションマッピング情報を第２計算装置から受信してもよい。第１計算装置は、少なくともキー情報に基づいて、要求をメタデータデータベースへ送信することを決定してもよい。第１計算装置は、パーティションマッピング情報に基づいて、キー情報に対応するメタデータデータベースの分割を維持するために示されている複数のメタデータノードの第１のメタデータノードを決定してもよい。第１計算装置は、データベース動作を実行するための要求を、パーティションマッピング情報に基づいて第１メタデータノードへ送信してもよい。
【0004】
詳細説明は添付図面を参照して記載される。図面では、参照番号の最も左の桁は参照番号が最初に出現する図を識別する。様々な図内の同じ参照番号の使用は同様又は同一なアイテム又は特徴を示す。
【図面の簡単な説明】
【0005】
【0006】
【0007】
【0008】
【0009】
【0010】
【0011】
【0012】
【0013】
【0014】
【0015】
【発明を実施するための形態】
【0016】
本明細書におけるいくつかの実施形態は、パーティション情報がシステム内の単一構成部又はテーブルに格納されない又はそれにより制御されない分散コンピュータシステムのための技術及び配置に向けられる。いくつかの例では、パーティションがオンラインになると、キー空間などの分割情報及び接続情報がクライアントアプリケーションへ提供されてもよい。さらに、クライアントアプリケーションは、接触すべき正しいノードを見つけるに複数のフォールバック機構を有してもよく、これによりいかなる単一点障害も防止する。加えて、パーティション情報に関与するクライアントアプリケーションを有することでデータ要求の最適ルーティングを可能にし得る。
【0017】
本明細書におけるいくつかの例は、高可用性スケーリング可能分散メタデータデータベースの要求をルーティングすることができるシステムを含む。本明細書におけるメタデータデータベースは、別のメタデータノード上に強い整合性のあるメタデータの複製を維持することにより高可用性を提供してもよい。さらに、メタデータデータベースは、メタデータを分割し、異なるメタデータノード全体にわたってこのメタデータを分散することによりスケーラビリティを提供する。各パーティションは、パーティションリーダとして働く単一メタデータノードを有してもよい。パーティションリーダはこの特定のパーティションのすべての要求に仕える責任があってもよい。さらに、本明細書における解決策は、クライアントアプリケーションが所与の要求のパーティションリーダを発見する能力を最適化する。
【0018】
上述のように、本明細書におけるいくつかの例は、強い整合性のあるメタデータの複製を複数のメタデータノードにわたり分散構成で格納することによりメタデータを高可用性にする。いくつかのケースでは、分散されたメタデータデータベースの整合性はラフト合意アルゴリズムを使用して維持される。ラフトアルゴリズムでは、１つのノードが、リーダとして選ばれ、すべての読み出し動作及び書込み動作を提供する責任があってもよい。他のノードは、それら自身のメタデータデータベース情報を更新することを可能にするためにすべてのトランザクションの複製を受信するフォロワノードである。リーダノードが故障すれば、フォロワノードのうちの１つが、リーダとして選ばれてもよく、そして読み出しトランザクション及び書込みトランザクションを提供することを引き継いてもよい。本明細書におけるメタデータシステムのクライアントノードは、どのノードがラフトリーダであるかを発見し、要求をそのノードへ向けることができる。パーティションのリーダが変われば、クライアントは新しいリーダへ自動的にルーティングされる。
【0019】
いくつかの例では、各クライアントはパーティション情報のニアキャッシュを維持してもよい。さらに、システムは、分散キャッシュに対する更新をクライアントへ発行し得る分散キャッシュを含んでもよい。さらに、本明細書におけるノードは、どこにデータが位置するかを示すヒントをクライアントへ提供してもよい。加えて、効率を維持するために、分散キャッシュの数は、システム内のノードの総数と比較して小さな数であってもよい。他方で、いくつかの例では、ニアキャッシュはクライアントの性能を改善するためにシステム内の各クライアント上に含まれてもよい。
【0020】
一例として、システムが、データを取り出すためのユーザ要求を、ユーザ装置から受信すると仮定する。この場合、ユーザ要求はニアキャッシュへ最初にルーティングされてもよい。定常状態中、クライアントは、典型的には、どのノードがユーザ要求に仕えることができるかに関する正しい答えをニアキャッシュ内に有していてもよい。この場合、クライアントは、正しいノードとの直接通信を行うことができることにより最適効率を達成し得る。例えば、ノードはデータのパーティションを提供する責任を負うので、ノードは、分散キャッシュに、当該ノードにより管理されるデータの新しいルーティング情報を通知してもよい。次に、分散キャッシュは、それぞれのニアキャッシュ内の格納のためにこの情報をクライアントへ発行し得る。
【0021】
いくつかのケースでは、ユーザ要求を受信するクライアントのニアキャッシュは古くなったマッピングを有し得る。したがって、ユーザ要求が、古くなったニアキャッシュ内で規定されるノードへルーティングされると、クライアントはノードから失敗応答を受信し得る。故障応答は、発見処理をトリガし得、ユーザ要求に応答するためにどのノードを次にチェックすべきかに関するヒントをさらに含み得る。閾値数の試行の間失敗が続けば、クライアントは各ノードを個々に照会することにフォールバックしてもよい。すべてのノードにポーリングすることから生じる性能は、極めて劣悪であり得るが、最悪のシナリオにおいて、クライアントが正しいノードを判断し、ユーザ要求を満たすことを可能にする。したがって、本明細書における実施形態は、データが成長又は収縮するにつれてパーティションが動的に追加及び除去されることを可能にすることなどにより、動的に拡張可能及び収縮可能である分散メタデータデータベースを有するシステムに提供する。システムは、システムメタデータをキャッシュする一組の階層的（ｔｉｅｒｅｄ）キャッシュを含んでもよく、複数の物理及び／又は論理ノードにわたって分散された大きな地理的に分散されたデータベースを実装する際に効率のための反応性キャッシュ更新機構を使用する。
【0022】
論述目的のために、いくつかの例示的実施形態は、分散されたメタデータデータベースを使用するデータの格納を管理するためのクラウドストレージシステムと通信する１又は複数のサービス計算装置の環境において説明される。しかし、本明細書における実施形態は、提供される特定例へ制限されることはなく、本明細書の開示に照らし当業者に明らかになるような他のタイプのコンピュータシステムアーキテクチャ、他のタイプのストレージ環境、他のタイプのクライアント構成、及び他のタイプのデータなどへ拡張され得る。
【0023】
図１はいくつかの実施形態に係るデータ及びメタデータを格納することができるシステム１００のアーキテクチャ例を示す。システム１００は、例えば１又は複数のネットワーク１０６を介して、少なくとも１つのネットワークストレージシステム１０４と通信することができる、又はそう接続される複数のサービス計算装置１０２を含む。さらに、サービス計算装置１０２は、以下に追加的に論述されるように様々なタイプの計算装置のいずれかであってもよい１又は複数のユーザ計算装置１０８及び１又は複数の管理者装置１１０とネットワーク１０６上で通信することができる。
【0024】
いくつかの例では、サービス計算装置１０２は任意数の方法で具現化され得る１又は複数のサーバを含んでもよい。例えば、サービス計算装置１０２のプログラム、他の機能構成部、及びデータストレージの少なくとも一部は、例えばサーバのクラスタ、サーバファーム、データセンタ、クラウドホスト型計算サービス等の内の、少なくとも１つのサーバ上に実装されてもよいが、他のコンピュータアーキテクチャが追加的に又は代替的に使用されてもよい。サービス計算装置１０２の追加詳細は図１１に関して以下に論述される。
【0025】
サービス計算装置１０２はストレージ及びデータ管理サービスをユーザ１１２へ提供するように構成されてもよい。いくつかの非限定的例として、ユーザ１１２は、いくつかの例では非常に大きな量のデータのストレージを含み得るビジネス、企業、組織、政府事業体、学術的事業体などのための機能を実行するユーザを含んでもよい。それにもかかわらず、本明細書における実施形態は、システム１００並びに本明細書において説明される他のシステム及び配置のためのいかなる特別な使用又は応用にも限定されない。
【0026】
ネットワークストレージシステム１０４は、いくつかの例では「クラウドストレージ」又は「クラウドベースストレージ」と呼ばれてもよく、いくつかのケースではサービス計算装置１０２において利用可能であり得るローカルストレージよりメガバイト／ギガバイト当たり低コストのストレージ解決策を可能にし得る。さらに、いくつかの例では、ネットワークストレージシステム１０４は本技術分野で知られているような商用クラウドストレージを含んでもよく、他の例では、ネットワークストレージシステム１０４はサービス計算装置１０２に関連する事業体だけによりアクセス可能な私的又は企業ストレージシステムを含んでもよく、又はその組み合わせを含んでもよい。
【0027】
１又は複数のネットワーク１０６は、インターネットなどの広域ネットワーク；イントラネットなどのローカルエリアネットワーク（ＬＡＮ）；セルラーネットワーク、Ｗｉ－Ｆｉなどのローカル無線ネットワーク、及び／又はブルートゥース（登録商標）などの短距離無線通信などの無線ネットワーク；ファイバーチャネル、光ファイバ、イーサーネット（登録商標）、又は任意の他のこのようなネットワーク、直接有線接続、又はそれらの任意の組み合わせ含む有線ネットワークを含む任意の好適なネットワークを含んでもよい。したがって、１又は複数のネットワーク１０６は有線及び／又は無線通信技術の両方を含んでもよい。このような通信に使用される構成部は、ネットワークのタイプ、選択される環境、又はその両方に少なくとも部分的に依存し得る。このようなネットワーク上で通信するためのプロトコルは周知であり、本明細書では詳細には論述されない。したがって、サービス計算装置１０２、ネットワークストレージシステム１０４、ユーザ装置１０８、及び管理装置１１０は、有線又は無線接続及びそれらの組み合わせを使用して１又は複数のネットワーク１０６上で通信することができる。
【0028】
加えて、サービス計算装置１０２は、１又は複数のネットワーク１０７上で互いに通信できてもよい。いくつかのケースでは、１又は複数のネットワーク１０７はＬＡＮ、私設ネットワークなどであってもよく、一方、他のケースでは、１又は複数のネットワーク１０７は上に論述されたネットワーク１０６のうちの任意のものを含んでもよい。
【0029】
各ユーザ装置１０８は、デスクトップ、ラップトップ、タブレット計算装置、モバイル装置、スマートフォン、ウェアラブル装置、端末、及び／又はネットワーク上でデータを送信することができる任意の他のタイプの計算装置などの任意の好適なタイプの計算装置であってよい。ユーザ１１２は、例えばそれぞれのユーザアカウント、ユーザログイン信用証明などを介して、ユーザ装置１０８にそれぞれ関連付けられてもよい。さらに、ユーザ装置１０８は、１又は複数のネットワーク１０６を介し、別のネットワークを介し、又は任意の他の好適なタイプの通信接続を介して、サービス計算装置１０２と通信できてもよい。非常に多くの他の変形形態が本明細書の開示の利益を有する当業者に明らかになる。
【0030】
さらに、各ユーザ装置１０８は、例えばサービス計算装置１０２上で実行可能なユーザウェブアプリケーション１１６との通信のために、例えばネットワークストレージシステム１０４上のストレージのためにユーザーデータを送信するために、及び／又はデータ要求１１８などを介してネットワークストレージシステム１０４から格納されたデータを受信するために、ユーザ装置１０８上で実行し得るユーザアプリケーション１１４のそれぞれのインスタンスを含んでもよい。いくつかのケースでは、アプリケーション１１４は、ブラウザを含んでもよいし又はブラウザを介して動作してもよく、一方で、他のケースでは、アプリケーション１１４は、１又は複数のネットワーク１０６上でユーザウェブアプリケーション１１６との通信を可能にする通信機能を有する任意の他のタイプのアプリケーションを含んでもよい。
【0031】
システム１００では、ユーザ１１２は、彼らのそれぞれのユーザ装置１０８が通信状態に在るサービス計算装置１０２へデータを格納し、又はサービス計算装置１０２からデータを受信してもよい。したがって、サービス計算装置１０２は、ユーザ１１２及びそれぞれのユーザ装置１０８のためにローカルストレージを提供してもよい。定常状態動作中、サービス計算装置１０２と定期的に通信するユーザ１０８が存在し得る。
【0032】
加えて、管理者装置１１０は、デスクトップ、ラップトップ、タブレットコンピュータ装置、モバイル装置、スマートフォン、ウェアラブル装置、端末、及び／又はネットワーク上でデータを送信することができる任意の他のタイプの計算装置などの任意の好適なタイプの計算装置であってもよい。管理者１２０は、それぞれの管理者アカウント、管理者ログイン信用証明などを介して管理者装置１１０に関連付けられてもよい。さらに、管理者装置１１０は、１又は複数のネットワーク１０６を介し、別個のネットワークを介し、又は任意の他の好適なタイプの通信接続を介してサービス計算装置１０２と通信することができ得る。
【0033】
さらに、各管理者装置１１０は、例えばサービス計算装置１０２上で実行可能である管理ウェブアプリケーション１２４との通信のために、例えばシステム１００を管理するための管理命令を送信するために、例えばネットワークストレージシステム１０４上のストレージのために管理データを送信するために、及び／又は例えば管理要求１２６などを介し、格納された管理データをネットワークストレージシステム１０４から受信するために、管理者装置１１０上で実行し得る管理者アプリケーション１２２のそれぞれのインスタンスを含んでもよい。いくつかのケースでは、管理者アプリケーション１２２はブラウザを含んでもよいし又はブラウザを介し動作してもよいが、他のケースでは、管理者アプリケーション１２２は、１又は複数のネットワーク１０６上での管理ウェブアプリケーション１２４との通信を可能にする通信機能を有する任意の他のタイプのアプリケーションを含んでもよい。
【0034】
サービス計算装置１０２は、例えばネットワークストレージシステム１０４へ格納されるデータを送信するために及びネットワークストレージシステム１０４から要求データを取り出すために、ゲートウエイをネットワークストレージシステム１０４へ提供し得るストレージプログラム１３０を実行してもよい。加えて、ストレージプログラム１４２は、例えばデータ保存期間、データ保護レベル、データ複製等を管理するために、システム１００により格納されたデータを管理してもよい。
【0035】
サービス計算装置１０２は、複数のサービス計算装置１０２にわたって分散され得、複数のメタデータＤＢ部１３４（１）－１３４（Ｎ）に分割され得るメタデータデータベース（ＤＢ）１３２をさらに含んでもよい。例えば、メタデータＤＢ１３２は、ネットワークストレージシステム１０４で格納されるオブジェクトデータ１３６を管理するために使用されてもよい。メタデータＤＢ１３２は、個々のオブジェクトに関する情報、個々のオブジェクトにアクセスする方法、オブジェクトのストレージ保護レベル、ストレージ保存期間、オブジェクト所有者情報、オブジェクトサイズ、オブジェクトタイプなどのオブジェクトデータ１３６に関する無数のメタデータを含んでもよい。さらに、ＤＢ管理プログラム１３８は、新しいオブジェクトが格納された、古いオブジェクトが消去された、オブジェクトが移動されたなどのメタデータＤＢ１３２を更新するなどのためにメタデータＤＢ１３２を管理及び維持してもよい。
【0036】
加えて、サービス計算装置１０２は、例えばそれぞれの部のパーティションが含まれるメタデータＤＢ部が格納される特定のサービス計算装置を追跡するためにメタデータＤＢ部１３４の位置を追跡し得る分散キャッシュ１４４を含んでもよい。いくつかのケースでは、ＤＢ管理プログラム１３８は、メタデータＤＢ１３２が更新され、異なるサービス計算装置１０２へ移動されるなどすると、分散キャッシュを更新してもよい。
【0037】
分散キャッシュ１４４内の情報は、ユーザウェブアプリケーション１１６及び管理ウェブアプリケーション１２４などのクライアントサービスを提供するアプリケーションを実行し得るサービス計算装置１４６のうちのいくつかの上に維持され得るニアキャッシュ１４６を更新するために使用されてもよい。例えば、ニアキャッシュは分散キャッシュ１４４に対する更新に基づき定期的に更新されてもよい。したがって、一例として、ユーザウェブアプリケーション１１６がユーザ装置１０８からデータ要求１１８を受信すると、ユーザウェブアプリケーションは、データ要求１１８を行うために所望のメタデータＤＢ部１３４にアクセスするためにどのサービス計算装置１０２と通信すべきかを判断するためにニアキャッシュ１４６にアクセスしてもよい。したがって、ニアキャッシュ１４６の使用により、ユーザウェブアプリケーションは、データ要求を行うためのメタデータＤＢ１３２から所望情報を取得するための問合せの数を低減することができる。分散キャッシュ１４４及びニアキャッシュ１４６の追加詳細が以下に論述される。
【0038】
加えて、サービス計算装置は、メタデータＤＢ１３２及び／又はオブジェクトデータ１３６に対する更新を実行するために実行され得る非同期管理プログラム１４８を含んでもよい。いくつかのケースでは、非同期管理プログラム１４８はストレージプログラム１３０のモジュールであってもよく、他のケースでは、非同期管理プログラム１４８は別のプログラムであってもよい。非同期管理プログラム１４８は、更新キュー又はデータストレージの他のデータ構造及びシステム１００において非同期的に実行される管理行為を維持してもよい。例えば、ユーザへ報告を返す前にいくつかの格納動作を実行し、これらの動作を完了しなければならないのではなく、非同期管理プログラム１４８は、同さが行われるということを保証するように構成され得るキューに対して必要な動作を維持してもよく、次に、いくつかタイプの動作のために含まれ得る遅延無しにユーザに応答し得る。次に、非同期管理プログラム１４８は、バックグラウンド動作などとして更新キュー内の動作を非同期に行ってもよい。
【0039】
いくつかのケースでは、サービス計算装置１０２は、サイト１５０において１又は複数のグループ、クラスタ、システムなど内へ配置されてもよい。いくつかのケースでは、複数のサイト１５０はデータ複製、災害復旧保護などを提供するなどのために地理的に互いに分散されてもよい。さらに、いくつかのケースでは、複数の異なるサイト１５０におけるサービス計算装置１０２は、例えば複数のサイト１５０の連合を提供するために互いに確実に通信するように構成されてもよい。
【0040】
いくつかの例では（図１に示さず）、サービス計算装置１０２のいくつかは、格納及びデータ管理サービスを複数のユーザ装置１０８へ提供するための計算ノードを併せて形成するように、第１サービス計算装置１０２を第２サービス計算装置１０２へ接続される対で配置されてもよい。例えば、第１サービス計算装置１０２は主計算装置として働いてもよい一方で、第２サービス計算装置１０２はバックアップ、フェイルオーバなどのための副計算装置として働いてもよい。さらに、以下に追加的に論述されるように、いくつかのケースでは、複数のサービス計算装置１０２は、複数の計算装置においてメタデータＤＢの冗長性を提供するなどのために、分割されたデータの管理のためのラフト構成で構成されてもよい。無数の他の構成は本明細書の開示の利益を受ける当業者に明らかになる。
【0041】
図２はいくつかの実施形態に係るシステム２００の論理構成例を示すブロック図である。いくつかの例では、システム２００は、上に論述されたシステム１００又は本明細書の開示の利益を得る当業者にとって明白になるであろう様々な他の潜在的計算システムアーキテクチャのうちの任意のものに対応してもよい。システム２００は、分散されたオブジェクトストレージを可能にし得、ユーザ及び管理者のためのフロントエンドとしてウェブアプリケーションの使用を含み得る。いくつかのケースでは、システム２００は、ユーザにより生成され得るバケットに、ネットワークストレージ上のオブジェクトを格納してもよい。システム２００は、オンプレミス及びクラウドシステムにわたって分散された資源を使用することにより、データの複雑な管理及び格納を可能にしてもよい。システム２００では、スケーラビリティは、地理的にわたって格納された格納データを論理的に分割することにより提供されてもよい。以下に追加的に論述されるように、システム２００は、ユーザ要求又はシステム要求に応答するなどのために、所望のメタデータの位置を判定するための効率的処理を含む。
【0042】
加えて、システム２００は、ネットワークストレージシステム１０４などにおいて、オブジェクトのメタデータ又はシステム２００により格納された他のデータを追跡するために、高可用性且つスケーラブルであり、分散されたメタデータＤＢ１３２を採用する分散オブジェクトストアを提供してもよい。システム２００は、メタデータＤＢ１３２内に格納されるメタデータを効率的に読み出し及び書き込むためにメタデータＤＢ１３２の個々のメタデータノード２０２へのアクセスを可能にするために階層的キャッシュを含む。この例では、メタデータＤＢ１３２は、図１に関し上述されたように、それぞれが、メタデータＤＢ部１３４を維持するサービス計算装置１０２のうちの１又は複数を含み得るメタデータノード２０２（１），２０２（２），２０２（３），．．．を含む。
【0043】
システム２００は、管理及びデータアクセスサービス並びに管理サービスをユーザ及び管理者それぞれへ提供するユーザウェブアプリケーション１１６、管理ウェブアプリケーション１２４をさらに含む。例えば、ユーザウェブアプリケーション１１６はクライアントモジュール２０４を含んでもよく、管理ウェブアプリケーション１２４は、クライアントモジュール２０６を含んでもよく、それぞれがシステム２００内の他のノードと相互作用するように構成されている。例えば、クライアントモジュール２０４、２０６は、メタデータを取り出すためにメタデータノード２０２と対話してもよく、関連するニアキャッシュ１４６（１）又は１４６（２）を更新するためにキャッシュ情報を受信するために分散キャッシュノードと対話してもよく、また、取り出されたメタデータに基づき例えばデータ２１０を取り出すためにストレージプログラム１３６と対話してもよい。
【0044】
システム２００はまた、非同期管理プログラム１４８を含んでもよく、また、非同期管理プログラム１４８は、システム内のデータ及びメタデータを処理し、維持し、反応するために、様々な非同期サービスを行っているときに、メタデータノード２０２、分散キャッシュノード２０８、及び／又はストレージプログラム１３６と通信できるクライアントモジュール２１２を含んでもよい。いくつかのケースでは、クライアント２１２は、関連するニアキャッシュ１４６へアクセスすることに基づいて、メタデータデータベース１３２へ効率的に接続し、そこから読み出す／そこへ書き込むことができてもよい。
【0045】
加えて、いくつかのケースでは、分散キャッシュノード２０８は、登録されたリスナ２１４を含んでもよい。以下に追加的に論述されるように、各ニアキャッシュ１４６（１）、１４６（２）、１４６（３）は、分散キャッシュノード２０８に登録された登録リスナ２１４を有してもよい。分散キャッシュ１４４に対して更新がされると、関連する登録されたリスナ２１４は、それぞれのニアキャッシュ１４６に対する更新に関する情報を送信してもよい。したがって、登録されたリスナは、ニアキャッシュ１４６が最新に保たれることを可能にし、これにより、クライアントモジュール２０４、２０６、２１２によるメタデータノードに対する不正呼び出しの数を低減する。
【0046】
図３はいくつかの実施形態によるメタデータノードパーティション３００の構成例を示すブロック図である。本明細書におけるメタデータノード２０２は、メタデータノード２０２により管理されるメタデータＤＢ部１３４の冗長バックアップを提供するためにラフト合意アルゴリズムに従ってそれぞれが動作するように構成される複数のパーティション３００内に構成されてもよい。例えば、ラフトアルゴリズムは、各メタデータノード２０２がメタデータＤＢ部１３４に対する同じ変更に同意するということを保証する。ラフトグループは、選ばれたリーダを介して合意を達成する、例えば、ラフトグループ内のメタデータノード２０２は、リーダ又はフォロワのいずれかであってもよい。リーダは、フォロワノードのメタデータＤＢ部１３４に対する変更の複製に責任があってもよい。リーダは、ハートビートメッセージを送信することにより、その存在をフォロワに定期的に通知してもよい。リーダが閾値期間内にハートビートメッセージを送信しなければ、フォロワは、フォロワの中から新しいリーダを選んでもよい。したがって、この例及び以下に論述される例では、各パーティション３００は、その特定のパーティションのすべての要求に仕える責任がある「パーティションリーダ」と呼ばれる単一リーダのメタデータノード２０２を有する。したがって、本明細書における実施形態により解決される１つの問題は、クライアントから所与の要求を送信すべき正しい分割リーダを最適に判断することである。
【0047】
図示の例では、メタデータノード２０２（１）はパーティション３００のパーティションリーダであり、メタデータノード２０２（２）及び２０２（３）はフォロワである。リーダとしてのメタデータノード２０２（１）は、レコードを生成するためのクライアント要求３０２を受信する。それに応じて、メタデータノード２０２（１）は、メタデータノード２０２（１）により管理されるメタデータＤＢ部１３４内に新レコード３０４を生成する。加えて、ラフトアルゴリズムに基づき、メタデータノード２０２（２）は、フォロワメタデータノード２０２（２）、２０２（３）に対して新レコード３０４を複製する。これらのメタデータノード２０２（２）、２０２（３）のそれぞれは、自身が管理するメタデータＤＢ部１３４へ新レコード３０４を追加する。
【0048】
さらに、この例では、「リーダ」と「フォロワ」との区別はメタデータノード２０２自体ではなくパーティションに関するものであるということが注目に値する。例えば、この例における「リーダ」メタデータノード２０２（１）は、このパーティションのためのリーダであるが、メタデータノード２０２（１）もまた管理する可能性がある１又は複数の他のパーティションのフォロワ又はリーダでもあり得る。
【0049】
したがって、図３の構成は、複数のメタデータノード２０２上にメタデータの強い整合性のある複製を作成することにより高可用性メタデータを提供する。本明細書における分散メタデータＤＢは、１又は複数のフォロワノードがすべてのトランザクションの複製を受信する確立されたラフトプロトコルを使用することにより、これを実現する。リーダノードが故障すれば、フォロワノードのうちの１つが、リーダとして選ばれ、読み出しトランザクション及び書込みトランザクションを提供することを引き継いでもよい。以下に追加的に論述されるように、メタデータＤＢのクライアントは、典型的には、関連するニアキャッシュを参照することに基づいて、どのノードがラフトリーダかを発見することができ、このノードに対するその要求を行うことができる。パーティションリーダが変われば、分散キャッシュ及びニアキャッシュは、クライアントがその新しいリーダへルーティングされるように更新される。
【0050】
図４はいくつかの実施形態に係る例示的データ構造４００を示すブロック図である。この例では、データ構造４００は、第１パーティション４０２、第２パーティション４０４及び第３パーティション４０６など複数のパーティションを記述するキー／値対を含む。データ構造４００は、キー４０８及び対応する値４１０を含む。
【0051】
本明細書におけるメタデータＤＢ内のメタデータの分割（また時折シャーディングと呼ばれる）は、システム内の相異なるメタデータノードにわたってメタデータの領域の責任を分割することによりメタデータＤＢのスケーリングを可能にする。この例では、メタデータＤＢの分割は、各メタデータテーブルのキー空間（すなわち一組の全ての可能なキー４０８）を、パーティションに関連するキー空間範囲へ分割することにより達成される。各パーティションは、パーティション識別子及びＤＢパーティションを管理するノードが責任を負う一組のキー空間範囲を与えられる。
【0052】
図示の例では、第１パーティション４０２はキーａ－ｅを含み；第２パーティション４０４はキーｅ－ｏを含み；第３パーティション４０６はキーｏ－ｚを含む。したがって、各組のメタデータノードにより管理されるメタデータＤＢ部は、上述の技術を使用することにより決定されたそれぞれのパーティションに対応してもよい。さらに、各メタデータノードにより管理されるデータ量をバランスするなどのために、パーティションは、各パーティション４０２－４０６内のデータ量の変化に基づいて定期的に調整されてもよい。
【0053】
図５はいくつかの実施形態に係る複数のメタデータノード２０２の例示的構成５００を示すブロック図である。この例では、ラフトグループは、メタデータノード２０２（１）－２０２（４）の下位集合上の３つのパーティション５０２、５０４、５０６のそれぞれに形成される。このラフトグループのリーダは、パーティションリーダであり、そのパーティションの他のメンバーに対するすべての要求を提供する責任がある。各メタデータノード２０２は、複数のラフトグループのメンバーであってもよく、したがって、複数のパーティションのメンバーであってもよい。いかなるメタデータノード２０２も自身が管理するパーティションのうちの任意のパーティションのリーダになってもよい。この例では、メタデータノード２０２（１）は、第１パーティション５０２をフォロワとして、第２パーティション５０４をフォロワとして、そして第３パーティション５０６をフォロワとして管理する。メタデータノード２０２（２）は第１パーティション５０２をリーダとして、第２パーティション５０４をフォロワとして管理する。メタデータノード２０２（３）は第２パーティション５０４をリーダとして、第３パーティション５０６をフォロワとして管理する。メタデータノード２０２（４）は、第１パーティションをフォロワとして、第３パーティション５０６をリーダとして管理する。
【0054】
メタデータシステムのクライアントは、ニアキャッシュ（図５に示さず）を参照することなどにより、どのノードが所与のメタデータＤＢアクセス要求のパーティションリーダかを発見することができる。パーティションリーダが変われば、クライアントは、以下に追加的に論述されるように、ニアキャッシュへ提供される更新情報に基づいて又は他の技術を介するなどして新しいリーダへルーティングされてもよい。
【0055】
パーティションはまた、いくつかのケースでは、分割され、マージされてもよい。パーティションを分割することは、単一パーティションにより提供されるキー空間範囲を２つ以上の新しいパーティションに分割することを意味する。パーティションを分割することは、パーティションに含まれるメタデータの量が大きくなり、メタデータをより大きな数のメタデータノードにわたって分散することが望ましいときに発生してもよい。他方で、パーティションのマージは、複数のパーティションのメタデータを一緒に連結して単一のパーティションにすることを含んでもよい。単一パーティションへマージされるメタデータは、後のパーティションアクセスのマージを単純化するために、隣接するキー空間範囲を有してもよい。パーティションをマージすることは、単一パーティション内の対応するメタデータを提供することがより効率的となる程度に、一組のパーティションが縮小したときに発生してもよい。
【0056】
図６はいくつかの実施形態に係るパーティションマッピングの例示的データ構造６００を示すブロック図である。この例では、データ構造６００は、パーティションＩＤ６０２、パーティションＩＤに対応するキー空間範囲６０４、パーティションのリーダのリーダＩＤ６０６、パーティションのメンバーであるノードのノードＩＤ６０８を含む。上述のように、所与の要求に関して、クライアントは、要求がどのパーティションに属するかを決定してもよい。これを行うために、クライアントは、要求のキーをキー空間範囲６０４の１つへマッピングしてもよい。次に、クライアントは、どのパーティションがそのキーを含むキー空間範囲６０４に責任があるかを決定してもよい。キー空間及び／又はパーティションが変われば、新しいパーティション、マージされたパーティションなどの場合に、クライアントが所望の情報を発見できるようにするために、データ構造は更新される必要があってもよい。
【0057】
パーティション情報をシステム構成部間で伝達するために、本明細書におけるシステムは、データ構造６００内に示すようなパーティションマップエントリを使用してもよい。パーティションマップエントリは、クライアントが要求をパーティションリーダへルーティングするために十分な情報を記述する。例えば、パーティションマップエントリは、鍵空間範囲を、各キー空間範囲のパーティションリーダであるノードのシステム独自の識別子に関係付ける。
【0058】
図７はいくつかの実施形態に係るメタデータノード２０２の構成例を示すブロック図である。本明細書におけるメタデータノード２０２は実データベースノードである。メタデータノード２０２は、メタデータ要求を処理し、メタデータを磁気ディスクなどの持続性ストレージ上などに格納してもよく、メタデータの一貫した高可用性及び耐久性を提供するためにラフトグループに参加してもよい。各メタデータノード２０２は、それぞれが異なるパーティションを表す複数の別々のラフトグループの一部であってもよ。メタデータノード２０２は、そのメンバーである任意のラフトグループのリーダに選ばれてもよく、この時点で、選ばれたリーダはそのパーティションの要求を処理する。
【0059】
図示の例では、メタデータノード２０２は、メタデータアプリケーションプログラムインターフェース（ＡＰＩ）サーバプログラム７０２を含む。加えて、このメタデータノード２０２は、第１パーティション７０４をリーダとして、第２パーティション７０６をリーダとして、そして第３パーティション７０８をフォロワとして管理する。メタデータノード２０２は、メタデータＡＰＩサーバプログラムを介して、第１パーティション７０４内のキーについてのクライアント要求７１０を受信してもよい。こに応じて、メタデータＡＰＩサーバプログラムは、関連するメタデータデータベース部から要求された情報を取得するために第１パーティション７０４にアクセスしてもよく、要求７１０を送信したクライアントへ要求された情報を返してもよい。
【0060】
各メタデータノード２０２はパーティションマップエントリとラフトグループとの間のパーティションマッピング７１２を維持してもよい。メタデータノード２０２がクライアントから要求を受信すると、パーティションマッピング７１２は、要求がどのラフトグループに属するかを判定するために相談されてもよい。メタデータノードが特定の要求のマッピングを有しなければ、エラーが、要求しているクライアントへ返されてもよい。そうでなければ、要求は正しいラフトグループへ転送される。メタデータノード２０２がこのラフトグループのリーダであれば、要求はメタデータノードにより処理される。そうでなければ、メタデータノードがこのラフトグループのフォロワである場合などでは、ラフトグループのリーダの接続情報を含むエラーが要求しているクライアントへ返される。したがって、要求しているクライアントは、返されたエラーメッセージ内にどのメタデータノードへ要求をリダイレクトするかに関するヒントが、提供される。
【0061】
パーティションメンバーシップイベント中、例えば、メタデータノードがリーダに選ばれれば、又は（メタデータノードの追加又は除去の場合などに）、リーダとしてのラフトグループメンバーシップが変わればメタデータノード２０２は新しいパーティションマップエントリを２つの場所へ提出してもよい。第１に、メタデータノード２０２は、ラフトグループに対してパーティションマップエントリの内部マッピング７１２を更新してもよく、メタデータノード２０２がそのパーティションに対する要求を処理することができるようにする。第２に、メタデータノード２０２は、パーティションマップエントリの分散キャッシュを更新し得るので、システムのクライアントは新しいルーティング情報を見ることができる。分散キャッシュが情報を失ってしまう障害に対して保護するために、メタデータノード２０２はそのパーティションマップエントリをキャッシュへ定期的に再送信してもよい。
【0062】
図８はいくつかの実施形態に係るシステム８００の構成例を示すブロック図である。いくつかの例では、システム８００は、上述されたシステム１００及び／又はシステム２００並びに他のシステムアーキテクチャに対応してもよい。システム８００内には３つの主構成部、つまりクライアント８０２、８０４と、分散キャッシュ１４４と、メタデータノード２０２（１）－２０２（４）とが存在する。
【0063】
分散キャッシュ１４４は、分散キャッシュノード２０８上に維持されてもよく、パーティションマップエントリをクライアント８０２、８０４（これは、上述されたクライアントモジュール２０４、２０６、２１２のうちの任意のもの又は本明細書におけるシステム内で動作し得る他のクライアントアプリケーションに対応してもよい）へ格納し分散するために使用されてもよい。いくつかの例では、分散キャッシュ１４４は、一時的であってもよく及び／又はインメモリのみであってもよい。分散キャッシュ１４４は、パーティションメンバーシップイベントにおいてメタデータノード２０２から送信された一組のパーティションマップエントリを含む。第１エントリ８０６、第２エントリ８０８及び第３エントリ８１０がこの例では示されている。
【0064】
図２に関して上述したように、クライアント８０２、８０４、及び図８に示さない他のクライアントは、分散キャッシュ１４４に対して変更が行われた時には、対応するニアキャッシュを更新するために使用されるリスナ２１４を登録してもよい。例えば、パーティションマップエントリが分散キャッシュ１４４へ送信されると、分散キャッシュノードは、登録されたリスナ２１４により各クライアントへの接続を開き、その更新をクライアントへ送信することになる。完全故障の場合、分散キャッシュ１４４は、メタデータノード２０２がそれらの現在のパーティションマップエントリを再送信すると受信され得る最新のエントリにより、例えば異なるノード上に再構築されてもよい。
【0065】
クライアント８０２及び８０４は、要求を例えばユーザから受信してもよく、対応する要求をメタデータデータベースへ送信してもよく、応答を受信してもよく、そして要求しているユーザへ応答を返してもよい。クライアントが開始すると、クライアントは、最初に分散キャッシュ１４４へ接続し、すべての既存のパーティションマップエントリを読み出してもよい。クライアントはこの情報をニアキャッシュ１４６として格納してもよい。加えて、クライアントは、すべての新しいパーティションマップエントリを受信するためにリスナ２１４を登録してもよい。
【0066】
図示の例では、メタデータノード２０２（１）－２０２（４）は３つのパーティション、つまり第１パーティション８１２、第２パーティション８１４、第３パーティション８１６を維持する。第１パーティション８１２のリーダはメタデータノード２０２（２）上にあり、第２パーティション８１４のリーダはメタデータノード２０２上にあり、第３パーティションのリーダはメタデータノード２０２（２）上にある。したがって、パーティションとエントリとの間のべた黒矢印により指示されるように、パーティショングループのリーダだけが分散キャッシュ１４４において対応するエントリを更新してもよい。さらに、破線矢印により指示されるように、エントリ８０６－８１０に対する更新は、ニアキャッシュ１４６を更新するためにクライアント８０２及び８０４へ伝播されてもよい。
【0067】
したがって、パーティションマップを含むシステムメタデータなどのメタデータだけが分散キャッシュ１４４内に格納される。分散されたマルチサイトの計算システム内の分散キャッシュ１４４の数は、システム内のノードの総数と比較して小さな数であってもよい。他方で、ニアキャッシュ１４６は、クライアント機能を有するシステム内のあらゆるノード上に存在してもよいが、場合によっては、古くなったデータを有してもよい。ユーザ要求は、典型的には、古くなった／パーティションマッピングに対する探索済みデータとなる可能性があるニアキャッシュ１４６へ最初にルーティングされてもよい。ルーティングされた要求が、それが向けられていたノードから障害応答を受信すれば、これは、送信するクライアント内の発見処理をトリガしてもよい。例えば、発見処理は、分散キャッシュ１４４の１つを操作することに関与してもよく、これはまたクライアントのニアキャッシュの更新を生じてもよい。パーティション情報が共有される分散キャッシュ及びニアキャッシュの使用は、典型的なクライアント要求が１つのネットワークホップを必要とすることだけを可能にしてもよい。分散キャッシュ１４４は、パーティションメンバーシップが変わるときはいつでも、メタデータノード２０２からの通知を介して更新されてもよく、次に、ニアキャッシュ１４６は、登録されたリスナ２１４に基づいて更新されてもよい。このようにして、すべてのクライアントニアキャッシュは、一元化された分散キャッシュ１４４における任意の更新に続くすべてのパーティション変更により最新の状態に保たれてもよい。分散キャッシュ１４４は高い可用性のために分散されてもよい。
【0068】
ニアキャッシュ１４６が古くなっており且つ分散キャッシュ１４４が利用不能である状況では、クライアントは要求を完了するために、個々のメタデータノード２０２をポーリングすることに頼ってもよい。ノード２０２のすべてをポーリングすることに関連するシステム性能は劣悪であり得るが、クライアントが要求を発見し、結果自体をキャッシュすることを依然として可能にする。発見のためのアルゴリズム例は、所望のメタデータキーを処理するパーティションのためのクライアントニアキャッシュをチェックすることを含んでもよい。キャッシュミスが発生すれば、クライアントは、メタデータキーを処理する分散キャッシュ１４４のパーティションをチェックしてもよい。キャッシュミス又は接続故障が発生すれば、サービス計算装置は正しいノードが発見されるまで、各メタデータノードに対して要求を実行することを試みてもよい。
【0069】
図９はいくつかの実施形態に係るキー空間ツリーデータ構造９００の構成例を示すブロック図である。受信されたそれぞれのパーティションマップエントリに関して、クライアントは２つのデータ構造を更新してもよい。第１データ構造（図９に示さず）は、マップエントリを分割するためのパーティションＩＤの単純なマッピングであってもよい。第２データ構造は、キー空間ＩＤをキー空間ツリーへマッピングすることを維持するキー空間ツリーデータ構造９００である。キー空間ツリーは、このキー空間範囲のパーティションＩＤへのキー空間範囲の下限からのツリーベースマッピングを含んでもよい。したがって、キー空間ツリーデータ構造９００は、所与の鍵の正しいパーティションＩＤを発見するために、効率的な対数時間で探索され得る。
【0070】
図９の例では、キー空間ツリーデータ構造９００は、４つのパーティション、つまり、キーＡ－Ｃを有する第１パーティション９０２、キーＣ－Ｈを有する第２パーティション９０４、キーＨ－Ｎを有する第３パーティション９０６、そしてキーＮ－Ｚを有する第４パーティションの例えば、Ａ、Ｃ、Ｈ、Ｎ、及びＲである上限のキー、つまり、を示している。図４において示されているように、これらの例ではシーリング文字は非包括的であるということに留意されたい。この例では、キーが「Ｊ」であると仮定すると、９１２において示されるように、クライアントは、ＪがＮより小さく、ＪがＣより大きく、ＪがＨより大きく、ＨがＪのフロアキーであることに基づいて、正しいパーティションを位置してもよく、したがって、９１４において示されるように、Ｊは第３のパーティション内にある。
【0071】
要求がユーザから来ると、クライアントは、その要求タイプについての提供されたマッピング機能を使用することにより、ユーザ要求のキー空間を判定してもよい。キー空間が判断されると、パーティションＩＤは、関連するキー空間ツリーデータ構造から発見され得る。次に、パーティションＩＤは、そのパーティションのためのラフトグループ内のメタデータノードを識別する、そのパーティションのためのパーティションマップエントリを発見するために使用されてもよい。次に、クライアントは、パーティションマップエントリ内のリーダとして識別されるノードへ第１要求を送信してもよい。本明細書におけるシステムの典型的な定常状態では、クライアントにより所有されるパーティションマッピングは最新の状態となり、要求は正しいパーティションリーダメタデータノードへ送信されることになる。クライアントにより接触されたメタデータノードはもはやそのパーティションのパーティションリーダでなければ、図７に関して上述されたように、例えば、別のノードが今やラフトグループのパーティションリーダであることを示すヒントが応答と共に与えられたかどうかを判定してもよい。そうであれば、クライアントはヒント内に示されているノードへ要求を送信する。もし、ヒントが無ければ、クライアントは、同じラフトグループ内にあるという表示を有するすべてのノードを最初にチェックすることに進んでもよい。ラフトグループ内の他のメタデータノードのいずれかが、どのノードがリーダかに関するヒントを提供すれば、クライアントはほのめかされたノードをチェックすることを優先することになる。クライアントがすべてのラフトグループノードを使い果たせば、クライアントはシステム内のすべてのメタデータノードをポーリングすることに進んでもよい。最悪の場合、パーティションのリーダのメタデータノードがなく、クライアントは、ユーザ及び／又は管理者へ伝播され得るエラーメッセージを返すことになる。
【0072】
図１０はいくつかの実施形態に係るメタデータ要求をルーティングするための処理例を示す流れ図である。処理は一連の動作を表す論理フロー図内のブロックの集合として示され、そのいくつか又はすべてはハードウェア、ソフトウェア又はそれらの組み合わせで実装されてもよい。ソフトウェアの文脈では、ブロックは、１又は複数のプロセッサにより実行されるとプロセッサに列挙動作を実行するようにプログラムする１又は複数のコンピュータ可読媒体上に格納されるコンピュータ実行可能命令を表してもよい。一般的に、コンピュータ実行可能命令は、特定機能を行う又は特定データタイプを実装するルーチン、プログラム、オブジェクト、構成部、データ構造などを含む。ブロックが説明される順番は制限として解釈されるべきでない。説明されたブロックのうちの任意数のブロックは、処理又は代替処理を実施するために任意の順番で及び／又は並列に組み合わせられ得、ブロックのすべてが実行される必要があるわけではない。論述目的のために、本明細書の例において、これらの処理は説明される環境、フレームワーク、及びシステムを参照して説明されることになるが、これらの処理は幅広い種類の他の環境、フレームワーク及びシステムにおいて実装されてもよい。図１０では、処理１０００は１又は複数のサービス計算装置１０２により少なくとも部分的に実行されてもよい。
【0073】
１００２において、メタデータデータベースは複数のパーティションへ分割され、複数のパーティションは複数のメタデータノードにわたって分散されてもよい。
【0074】
１００４において、複数のパーティションについてのパーティションマッピング情報は分散キャッシュノードに格納されてもよい。
【0075】
１００６において、クライアント計算装置は、パーティションマッピング情報を分散キャッシュノードから受信してもよく、パーティションマッピング情報をローカルコンピュータ可読媒体上に格納してもよい。
【0076】
１００８において、クライアント計算装置は、分散キャッシュノードにおけるパーティションマッピング情報の変化に応答して、クライアント計算装置においてパーティションマッピング情報に対する更新を受信するために分散キャッシュノードにおいて要求を登録してもよい。
【0077】
１０１０において、クライアント計算装置は、分散キャッシュノードにおけるパーティションマッピング情報の変化に応答して、パーティションマッピング情報に対する更新を受信してもよい。
【0078】
１０１２において、クライアント計算装置は、受信された更新に基づき、クライアント計算装置において格納されたパーティションマッピング情報を更新してもよい。
【0079】
１０１４において、クライアント計算装置は、第１メタデータがキー情報と関連付けられている、第１メタデータについてのメタデータデータベースに対してデータベース動作を実行することを判定してもよい。
【0080】
１０１６において、クライアント計算装置は、キー情報に対応するメタデータデータベースのパーティションを維持する複数のメタデータノードの内の第１メタデータノードを決定するためにパーティションマッピング情報にアクセスしてもよい。
【0081】
１０１８において、クライアント計算装置は、パーティションマッピング情報に基づいて、第１メタデータのデータベース動作を実行するための要求を第１メタデータノードへ送信してもよい。
【0082】
本明細書において説明される例示的処理は論述目的のために提供される処理の単に一例である。無数の他の変形形態が本明細書の開示に照らして当業者に明らかになる。さらに、本明細書の開示は処理を実行するための好適なフレームワーク、アーキテクチャ及び環境のいくつかの例を記載するが、本明細書における実施形態は示され論述された特定例に限定されない。さらに、本開示は添付図面において説明及び示したように様々な実施例を提供する。しかし、本開示は、本明細書で説明され示された実施形態に限定されないが、当業者に知られているであろうように又は知られるようになるであろうように他の実施形態へ拡張し得る。
【0083】
図１１は、少なくとも本明細書において説明されるシステムの機能のうちのいくつかの機能を実装するために使用されてもよいサービス計算装置１０２の精選された構成部例を示す。サービス計算装置１０２は、１又は複数のサーバ、又は任意数のやり方で具現化され得る他のタイプの計算装置を含んでもよい。例えば、サーバの場合、プログラム、他の機能構成部、及びデータは、単一サーバ上、サーバのクラスタ、サーバファーム又はデータセンタ、クラウドホスト型コンピュータサービス等上に実装されてもよいが、他のコンピュータアーキテクチャが追加的に又は代替的に使用されてもよい。複数のサービス計算装置１０２は、例えば仮想サーバ、サーババンク、及び／又はサーバファームとして併せて又は別々に配置され、編成されてもよい。説明された機能は、単一事業体又は企業のサーバにより提供されてもよいし、複数の異なる事業体又は企業のサーバ及び／又はサービスにより提供されてもよい。
【0084】
図示の例では、サービス計算装置１０２は１又は複数のプロセッサ１１０２、１又は複数のコンピュータ可読媒体１１０４及び１又は複数の通信インターフェース１１０６を含んでもよいし、それらと関連付けられてもよい。各プロセッサ１１０２は、単一処理ユニット又は多数の処理ユニットであってもよく、単一又は複数の計算ユニット若しくは処理コアを含んでもよい。プロセッサ１１０２は、１又は複数の中央処理ユニット、マイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタル信号プロセッサ、ステートマシン、論理回路、及び／又は動作命令に基づいて信号を処理する任意の装置として実装されてもよい。一例として、プロセッサ１１０２は、本明細書において説明されるアルゴリズム及び処理を実行するように特別にプログラム又は構成された任意の好適なタイプの１又は複数のハードウェアプロセッサ及び／又は論理回路を含んでもよい。プロセッサ１１０２は、本明細書において説明される機能をプロセッサ１１０２に実行するにプログラムし得るコンピュータ可読媒体１１０４内に格納されているコンピュータ可読命令をフェッチ及び実行するように構成されてもよい。
【0085】
コンピュータ可読媒体１１０４は、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータなどの情報の格納のための任意のタイプの技術で実現される揮発性及び非揮発性メモリ並びに／又は着脱可能及び着脱不能媒体を含んでもよい。例えば、コンピュータ可読媒体１１０４は、限定しないがＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、光学ストレージ、ソリッドステートストレージ、磁気テープ、磁気ディスクストレージ、ＲＡＩＤストレージシステム、ストレージアレイ、ネットワーク接続ストレージ、ストレージエリアネットワーク、クラウドストレージ、又は所望情報を格納するために使用され、且つ計算装置によりアクセスされ得る任意の他の媒体を含んでもよい。サービス計算装置１０２の構成に依存して、コンピュータ可読媒体１１０４は、非一時的コンピュータ可読媒体がエネルギー、搬送波信号、電磁波、及び／又は信号それ自体などの媒体を排除すると述べる限りにおいて、有形な非一時的媒体であってもよい。いくつかのケースでは、コンピュータ可読媒体１１０４はサービス計算装置１０２と同じ場所にあってもよい、一方、他の例では、コンピュータ可読媒体１１０４はサービス計算装置１０２から部分的に離れていてもよい。例えば、いくつかのケースでは、コンピュータ可読媒体１１０４は、図１に関して上述されたネットワークストレージ１２０内のストレージの一部を含んでもよい。
【0086】
コンピュータ可読媒体１１０４はプロセッサ１１０２により実行可能である任意数の機能構成部を格納するために使用されてもよい。多くの実施形態では、これらの機能構成部は、プロセッサ１１０２により実行可能である命令又はプログラムであって実行されると本明細書ではサービス計算装置１０２に帰する動作を実行するようにプロセッサ１１０２を特にプログラムし得る命令又はプログラムを含む。コンピュータ可読媒体１１０４内に格納された機能構成部は、それぞれが１又は複数のコンピュータプログラム、アプリケーション、実行可能コード又はその一部を含み得るユーザウェブアプリケーション１１６、管理ウェブアプリケーション１２４、ストレージプログラム１３０、データベース管理プログラム１３８、非同期管理プログラム１４８、及びメタデータＡＰＩサーバプログラム７０２を含んでもよい。さらに、これらのプログラムはこの例では併せて示されたが、使用中、これらのプログラムの一部又はすべては別のサービス計算装置１０２上で実行されてもよい。
【0087】
加えて、コンピュータ可読媒体１１０４は、本明細書において説明される機能及び処理を実行するために使用されるデータ、データ構造及び他の情報を格納してもよい。例えば、コンピュータ可読媒体１１０４はメタデータデータベース１３２、分散キャッシュ１４４、ニアキャッシュ１４６を格納してもよい。さらに、これらのデータ構造はこの例では併せて示されたが、使用中、これらのデータ構造の一部又はすべては別個のサービス計算装置１０２上に格納されてもよい。サービス計算装置１０２はまた、プログラム、ドライバなどを含み得る他の機能構成部及びデータ並びに機能構成部により使用又は生成されるデータを含んでもよく又は維持してもよい。さらに、サービス計算装置１０２は多くの他の論理構成部、プログラム構成部、及び物理構成部を含んでもよいが、上述のものは本明細書における論述に関連する単なる例である。
【0088】
１又は複数の通信インターフェース１１０６は、１又は複数のネットワーク１０６上などの様々な他の装置との通信を可能にするための１又は複数のソフトウェア及びハードウェア構成部を含んでもよい。例えば、通信インターフェース１１０６は、本明細書の他のどこかで追加的に列挙されるようなＬＡＮ、インターネット、ケーブルネットワーク、セルラーネットワーク、無線ネットワーク（例えばＷｉ－Ｆｉ）及び有線ネットワーク（例えばファイバーチャネル、光ファイバ、イーサーネット）、直接接続、並びにＢＬＵＥＴＯＯＴＨ（登録商標）などの近距離通信等々のうちの１又は複数を介した通信を可能にしてもよい。
【0089】
本明細書において説明される様々な命令、方法、及び技術は、コンピュータ可読媒体上に格納され本明細書のプロセッサにより実行されるコンピュータプログラム及びアプリケーションなどのコンピュータ実行可能命令の一般的文脈において考慮されてもよい。一般的に、用語プログラム及びアプリケーションは、交換可能に使用されてもよく、特定タスクを行う又は特定データタイプを実現するための命令、ルーチン、モジュール、オブジェクト、部品、データ構造、実行可能コードなどを含んでもよい。これらのプログラム、アプリケーションなどは仮想マシン又は他のジャストインタイムコンパイル実行環境などにおいて固有コードとして実行されてもよいし、ダウンロードされ実行されてもよい。典型的には、プログラム及びアプリケーションの機能は、様々な実施形態において所望に従って組み合わせられてもよいし分散されてもよい。これらのプログラム、アプリケーション、及び技術の実施形態はコンピュータ記憶媒体上に格納されてもよいし通信媒体のある形式にわたって送信されてもよい。
【0090】
本主題は構造的特徴及び／又は方法論的行為に固有の言語で説明されたが、添付の特許請求の範囲において定義される主題は必ずしも特定の特徴又は行為に限定されないということを理解すべきである。むしろ、特定の特徴及び行為は特許請求の範囲を実現する例示的形式として開示される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
