特表2023-537703複数のパーティショングループ間のハートビート通信のランダム化
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-09-05
(54)【発明の名称】複数のパーティショングループ間のハートビート通信のランダム化
(51)【国際特許分類】
G06F 11/20 20060101AFI20230829BHJP
G06F 13/10 20060101ALI20230829BHJP
G06F 16/27 20190101ALI20230829BHJP
G06F 3/06 20060101ALI20230829BHJP
H04L 67/145 20220101ALI20230829BHJP
【ＦＩ】
G06F11/20 669
G06F13/10 340A
G06F16/27
G06F3/06 301M
H04L67/145
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023507340
(86)(22)【出願日】2020-08-03
(85)【翻訳文提出日】2023-02-22
(86)【国際出願番号】 US2020044704
(87)【国際公開番号】W WO2022031258
(87)【国際公開日】2022-02-10
(81)【指定国・地域】
(71)【出願人】
【識別番号】520155228
【氏名又は名称】ヒタチ ヴァンタラ エルエルシー
(74)【代理人】
【識別番号】110000279
【氏名又は名称】弁理士法人ウィルフォート国際特許事務所
(72)【発明者】
【氏名】ラッシュ， デイビッド， ジュニア．
(72)【発明者】
【氏名】グリマルディ，ケビン カヌエッテ
【テーマコード（参考）】
5B034
5B175
【Ｆターム（参考）】
5B034CC04
5B034DD02
5B175AA01
(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】
本主題は、構造上の特徴及び／又は方法論的な行為に固有の言語によって説明されてきたが、添付の特許請求の範囲に定める本主題は記載した特定の特徴又は動作に必ずしも限定されないことを理解すべきである。むしろ特定の特徴及び行為は、特許請求の範囲を実装する形態の例として開示されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【国際調査報告】