特許 7191493 スケジュール設定されたアンチエントロピー修復の設計のための技法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-12-09

(45)【発行日】2022-12-19

(54)【発明の名称】スケジュール設定されたアンチエントロピー修復の設計のための技法

(51)【国際特許分類】

   G06F 16/182 20190101AFI20221212BHJP

   G06F 9/48 20060101ALI20221212BHJP

【ＦＩ】

G06F16/182

G06F9/48 300Z

【請求項の数】 15

(21)【出願番号】P 2020551800

(86)(22)【出願日】2019-03-27

(65)【公表番号】

(43)【公表日】2021-11-25

(86)【国際出願番号】 US2019024417

(87)【国際公開番号】W WO2019191320

(87)【国際公開日】2019-10-03

【審査請求日】2021-05-20

(31)【優先権主張番号】62/648,907

(32)【優先日】2018-03-27

(33)【優先権主張国・地域又は機関】US

(73)【特許権者】

【識別番号】506267178

【氏名又は名称】ネットフリックス・インコーポレイテッド

【氏名又は名称原語表記】ＮＥＴＦＬＩＸ， ＩＮＣ．

(74)【代理人】

【識別番号】100073184

【弁理士】

【氏名又は名称】柳田 征史

(74)【代理人】

【識別番号】100123652

【弁理士】

【氏名又は名称】坂野 博行

(74)【代理人】

【識別番号】100175042

【弁理士】

【氏名又は名称】高橋 秀明

(72)【発明者】

【氏名】シェラ，ヴィネイ

(72)【発明者】

【氏名】リンチ，ジョゼフ

(72)【発明者】

【氏名】ウパディアイ，アジェイ

【審査官】齊藤 貴孝

(56)【参考文献】

【文献】米国特許出願公開第２０１６／０２９９９３７（ＵＳ，Ａ１）

【文献】米国特許出願公開第２０１０／０３１８６６３（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０２１４３１９４（ＣＮ，Ａ）

【文献】特開２０１２－２５２５４０（ＪＰ，Ａ）

【文献】特開２０１０－１４０３９６（ＪＰ，Ａ）

【文献】特開２００５－３５２７０８（ＪＰ，Ａ）

【文献】特表２０１６－５３４４７１（ＪＰ，Ａ）

【文献】特開２０１８－０１０５７６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／０２８６２０８（ＵＳ，Ａ１）

【文献】田中 直行 、外１名，ＤＢレプリケーション，ＰＦＵ・テクニカルレビュー，日本，株式会社ＰＦＵ，1998年05月01日，第９巻，第１号，ｐ．２６－３３

(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】

【図1】本発明の様々な実施形態による、コンテンツサーバ及びエンドポイントデバイスにコンテンツを分配するためのネットワークインフラストラクチャ

【図2】本発明の様々な実施形態による、図１のネットワークインフラストラクチャと合わせて実装できるコンテンツサーバの更に詳細な図

【図3】本発明の様々な実施形態による、図１のネットワークインフラストラクチャと合わせて実装できるコンテンツサーバの更に詳細な図

【図4】本発明の様々な実施形態による、図１のネットワークインフラストラクチャと合わせて実装できるエンドポイントデバイスの更に詳細な図

【図5A】本発明の様々な実施形態による、分散データベースネットワークの複数のコンテンツサーバにわたって分散アンチエントロピー修復手順を実施するための方法ステップのフロー図

【図5B】図５Ａから続くフロー図

【発明を実施するための形態】

【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】

【表1】

【0044】

「タイプ」修復オプションは、実行されるアンチエントロピー修復手順のタイプを指定する。フル修復の場合、コンテンツサーバ１１０は全てのパーティションに対して修復を実施する。インクリメンタル修復の場合、コンテンツサーバ１１０は、変化したデータに対してのみ修復を実施する。デフォルトの修復タイプは完全修復である。

【0045】

「ワーカー」修復オプションは、修復を実行するプロセッサコア（本明細書中では「ワーカー」とも呼ばれる）の個数を指定する。デフォルトのワーカーの個数は、最大１コア、及び利用可能なコアの個数を２で除算したものである。このデフォルトのワーカーの個数は、少なくとも１つ、かつ利用可能なコアの個数の半分以下のプロセッサコア上で修復を実行する。

【0046】

「並列度」修復オプションは、修復を実行するためのマークルツリーを計算する際に採用される並列度を指定する。３つの地理的に分散されたデータセンターそれぞれに３つのコンテンツサーバ１１０を含むクラスタ１４０に関して、「ｓｅｑｕｅｎｔｉａｌ」は、９個のコンテンツサーバ１１０にマークルツリーを順次構築させ、この場合、いずれの所与の時点において１つのコンテンツサーバ１１０のみがマークルツリーを構築する。「ｐａｒａｌｌｅｌ」は、ある所与のデータセンター内の３つのコンテンツサーバ１１０に、同時にマークルツリーを構築させる。複数のデータセンターがマークルツリーを順次構築し、この場合、いずれの所与の時点において、１つのデータセンター内のコンテンツサーバ１１０のみがマークルツリーを構築する。「ｄｃ＿ｐａｒａｌｌｅｌ」は、３つ全てのデータセンターにわたる９個全てのコンテンツサーバ１１０に、同時にマークルツリーを構築させる。デフォルトの並列度は「ｓｅｑｕｅｎｔｉａｌ」である。「ｓｅｑｕｅｎｔｉａｌ」はこれら３つのオプションの中で最も遅いものとなり得るが、「ｓｅｑｕｅｎｔｉａｌ」はデータ保存の観点から最も保守的でもある。

【0047】

「フック」修復オプションは、対応する１つのコンテンツサーバ１１０及び近隣のコンテンツサーバ１１０がノードリペアを完了した後で実行される修復後フックのセットを指定する。利用可能な修復後フックとしては、「ｃｌｅａｎｕｐ」、「ｃｏｍｐａｃｔｉｏｎ」、及びユーザが供給する他のいずれの修復後フックが挙げられる。デフォルトのフックは「ｃｌｅａｎｕｐ」である。

【0048】

「分割範囲」修復オプションは、ｒｅｐａｉｒ＿ｓｔａｔｕｓ状態テーブルを部分範囲のために分割するためのパーティションの個数を指定する。「分割範囲」が整数「ｎ」を指定している場合、ノード修復は、各パーティションが「ｎ」個の部分範囲に分割されるように実行される。「分割範囲」が、整数「ｎ」及びそれに続く「＿ｄｒｙ＿ｒｕｎ」を指定している場合、ノード修復は、各パーティションが「ｎ」個の部分範囲に分割され、かつ追加の診断データがｒｅｐａｉｒ＿ｓｔａｔｕｓ状態テーブルに保存されるように実行される。「分割範囲」が「ａｄａｐｔｉｖｅ」を指定している場合、ノード修復は、本明細書中で更に説明されているような適応分割範囲プロセスを実行する。デフォルトの「分割範囲」は、「ａｄａｐｔｉｖｅ」である。

【0049】

「修復間遅延分数」修復オプションは、あるアンチエントロピー修復手順の完了と次のアンチエントロピー修復手順の開始との間の遅延の分数を整数で指定する。「修復間遅延分数」の値フルは、次の修復の開始が、１つ前のアンチエントロピー修復の完了の１４４０分（２４時間）後に発生することを示す。「修復間遅延分数」の値インクリメンタルは、次の修復の開始が、１つ前のアンチエントロピー修復の完了後すぐに発生することを示す。

【0050】

「プロセスタイムアウト秒数」修復オプションは、別のコンテンツサーバ１１０がある状態から別の状態に遷移するのを待機する秒数を整数で指定する。デフォルトの「プロセスタイムアウト秒数」は１８００秒（３０分）である。

【0051】

「修復タイムアウト秒数」修復オプションは、単一の部分範囲の修復の完了を待機する秒数を整数で指定する。デフォルトの「修復タイムアウト秒数」は１４，４００秒（４時間）である。

【0052】

様々な実施形態では、現在実行中の修復手順の状態をチェック又は変更するために、本明細書中では「ノードツール（ｎｏｄｅｔｏｏｌ）」と呼ばれる２つの補足的なコマンドを利用できる。上記２つの補足的なコマンドは、コンテンツサーバ１１０の修復履歴をチェックするためのｒｅｐａｉｒｓｔａｔｕｓコマンドと、クラスタ１４０の修復を制御するためのｒｅｐａｉｒｃｔｌコマンドとを含む。これより、これらのノードツールコマンドそれぞれについて、更に詳細に記載する。

【0053】

ｒｅｐａｉｒｓｔａｔｕｓコマンドの構造を以下の表２に示す：

【0054】

【表2】

【0055】

行００１及び００２は、修復履歴情報を印刷するためのコマンドとして、名称「ｎｏｄｅｔｏｏｌ ｒｅｐａｉｒｓｔａｔｕｓ」を指定する。行００３～００６はｒｅｐａｉｒｓｔａｔｕｓコマンドの概要を示し、これは、行００５～００６に示され、かつ行００７～０１６に更に完全に記載される、４つのコマンドオプションを含む。行００８～０１０は、ｒｅｐａｉｒ－ｉｄコマンドオプションを示す。ｒｅｐａｉｒ－ｉｄが指定されている場合、ｒｅｐａｉｒｓｔａｔｕｓコマンドは、指定された修復識別子に関するステータスを返す。ｒｅｐａｉｒ－ｉｄが指定されていない場合、ｒｅｐａｉｒｓｔａｔｕｓコマンドは修復全体のステータスを返す。行０１１～０１２は、ｎｏｄｅ－ｉｄコマンドオプションを示す。ｒｅｐａｉｒｓｔａｔｕｓコマンドは、指定されたノード識別子に関するステータスを返す。行０１３～０１４は、ｋｅｙｓｐａｃｅコマンドオプションを示す。ｒｅｐａｉｒｓｔａｔｕｓコマンドは、指定された鍵空間に関するステータスを返す。行０１５～０１６は、ｔａｂｌｅコマンドオプションを示す。ｒｅｐａｉｒｓｔａｔｕｓコマンドは、指定された状態テーブルに関するステータスを返す。

【0056】

例えば、いずれのコマンドオプションも伴わないコマンド「ｎｏｄｅｔｏｏｌ ｒｅｐａｉｒｓｔａｔｕｓ」は、直近の修復ステータスのグローバルビューを返す。コマンド「ｎｏｄｅｔｏｏｌ ｒｅｐａｉｒｓｔａｔｕｓ －－ｒｅｐａｉｒ－ｉｄ １２」は、識別子１２を有する修復の修復ステータスを返す。コマンド「ｎｏｄｅｔｏｏｌ ｒｅｐａｉｒｓｔａｔｕｓ －－ｎｏｄｅ－ｉｄ ７３ａｂ７ｅ４９」は、識別子７３ａｂ７ｅ４９を有するノードの修復ステータスを返す。

【0057】

ｒｅｐａｉｒｃｔｌコマンドの構造を以下の表３に示す：

【0058】

【表3】

【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】

２．上記第２のアンチエントロピー修復手順の開始準備ができていることを判断する上記ステップは、現時点が、修復動作のために指定された特定の時間範囲内であることを判断するステップを含む、第１項に記載のコンピュータ実装型の方法。

【0091】

３．上記複数のノードに含まれる第２のノードによって、第３のアンチエントロピー修復手順の開始準備ができていることを判断するステップ；上記第３のアンチエントロピー修復手順に関連する１つ以上の操作を実行するためのスケジュールを生成するステップ；及び上記スケジュールを第２の共有修復スケジュールデータ構造に書き込んで、上記複数のノードに含まれる複数のノードにわたって上記第３のアンチエントロピー修復手順を開始するステップを更に含む、第１項又は第２項に記載のコンピュータ実装型の方法。

【0092】

４．上記第２のアンチエントロピー修復手順はフルアンチエントロピー修復手順を含み、上記第３のアンチエントロピー修復手順はインクリメンタルアンチエントロピー修復手順を含み、上記第３のアンチエントロピー修復手順の開始準備ができていることを判断する上記ステップは、インクリメンタル修復を含む第４のアンチエントロピー修復手順が終了したことを判断するステップを含む、第１～３項のいずれか１つに記載のコンピュータ実装型の方法。

【0093】

５．上記複数のノードに含まれる第２のノードによって、上記第２のアンチエントロピー修復手順が進行中であることを判断するステップ；上記第２のアンチエントロピー修復手順が、修復について次の順番であることを判断するステップ；及び上記第２のノード上に存在する少なくとも１つの整合性を失ったデータパーティションを修復するステップを更に含む、第１～４項のいずれか１つに記載のコンピュータ実装型の方法。

【0094】

６．上記複数のノードに含まれる第２のノードによって、上記第２のアンチエントロピー修復手順が進行中であることを判断するステップ；上記第２のノードが、上記第２のアンチエントロピー修復手順に関連する修復を現在実施している上記複数のノードに含まれる他の全てのノードから独立していることを判断するステップ；及び上記第２のノード上に存在する少なくとも１つの整合性を失ったデータパーティションを修復するステップを更に含む、第１～５項のいずれか１つに記載のコンピュータ実装型の方法。

【0095】

７．上記複数のノードに含まれる第２のノードによって、上記第２のアンチエントロピー修復手順が進行中であることを判断するステップ；上記第２のノードが、上記第２のアンチエントロピー修復手順に関連する修復を実施したことを判断するステップ；上記第２のノードと相互依存関係にある、上記複数のノードに含まれる他の全てのノードが、上記第２のアンチエントロピー修復手順に関連する修復を実施したことを判断するステップ；及び上記第２のノードによって、上記第２のアンチエントロピー修復手順に関連する修復後手順を実施するステップを更に含む、第１～６項のいずれか１つに記載のコンピュータ実装型の方法。

【0096】

８．上記修復後手順を実施する上記ステップは、上記第２のアンチエントロピー修復手順の完了後には不要であるパーティションを削除するステップを含む、第１～７項のいずれか１つに記載のコンピュータ実装型の方法。

【0097】

９．上記修復後手順を実施する上記ステップは、上記第２のノードに関連する１つ以上のパーティションに対して圧縮操作を実施して、上記１つ以上のパーティションへのアクセス時のレイテンシを低減するステップを含む、第１～８項のいずれか１つに記載のコンピュータ実装型の方法。

【0098】

１０．上記修復後手順を実施する上記ステップは、上記第２のノードが上記第２のアンチエントロピー修復手順に関連する上記修復を実施したことを示すメッセージを、監視アプリケーションに送信するステップを含む、第１～９項のいずれか１つに記載のコンピュータ実装型の方法。

【0099】

１１．上記第２のアンチエントロピー修復手順に関連するパーティションの個数が閾値レベルを超えることを判断するステップ；及び上記第２のアンチエントロピー修復手順に関連する作業を複数の部分範囲に分割するステップを更に含む、第１～１０項のいずれか１つに記載のコンピュータ実装型の方法。

【0100】

１２．上記第２のアンチエントロピー修復手順に関連する１つ以上のパーティションのサイズが閾値レベルを超えることを判断するステップ；及び上記第２のアンチエントロピー修復手順に関連する作業を複数の部分範囲に分割するステップを更に含む、第１～１１項のいずれか１つに記載のコンピュータ実装型の方法。

【0101】

１３．上記第２のアンチエントロピー修復手順のための完了時間が閾値レベルを超えることを判断するステップ；及び上記第２のアンチエントロピー修復手順に関連する作業を、上記完了時間に基づいて、複数の部分範囲に分割するステップを更に含む、第１～１２項のいずれか１つに記載のコンピュータ実装型の方法。

【0102】

１４．いくつかの実施形態では、１つ以上の非一時的コンピュータ可読ストレージ媒体は、１つ以上のプロセッサによって実行された場合に上記プロセッサに以下のステップ：第１のアンチエントロピー修復手順が終了したことを判断するステップ；複数のノードに含まれる第１のノードによって、かつ上記複数のノードに含まれる他の全てのノードによるより前に、第２のアンチエントロピー修復手順の開始準備ができていることを判断するステップ；上記第２のアンチエントロピー修復手順に関連する動作を実行するためのスケジュールを生成するステップ；及び上記スケジュールを共有修復スケジュールデータ構造に書き込んで、上記複数のノードに含まれる複数のノードにわたって上記第２のアンチエントロピー修復手順を開始するステップを実施させる、命令を含む。

【0103】

１５．上記第２のアンチエントロピー修復手順の開始準備ができていることを判断する上記ステップは、現時点が、修復動作のために指定された特定の時間範囲内であることを判断するステップを含む、第１４項に記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。

【0104】

１６．上記複数のノードに含まれる各ノードは、上記第２のアンチエントロピー修復手順に関連する修復を順次実施する、第１４項又は第１５項に記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。

【0105】

１７．上記複数のノードに含まれる第１のノードのサブセットに含まれる各ノードは、上記第２のアンチエントロピー修復手順に関連する修復を互いに並列に実施し；上記複数のノードに含まれる第２のノードのサブセットに含まれる各ノードは、上記第２のアンチエントロピー修復手順に関連する修復を互いに並列に実施し；上記第１のノードのサブセットに含まれる上記ノードは、上記第２のノードのサブセットに含まれる上記ノードに対して、上記第２のアンチエントロピー修復手順に関連する上記修復を順次実施する、第１４～１６項のいずれか１つに記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。

【0106】

１８．上記複数のノードに含まれる各ノードは、上記第２のアンチエントロピー修復手順に関連する修復を互いに並列に実施する、第１４～１７項のいずれか１つに記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。

【0107】

１９．いくつかの実施形態では、計算デバイスは、命令を含むメモリと、上記メモリに結合されたプロセッサであって、上記命令を実行したときに：第１のアンチエントロピー修復手順が終了したことを判断し；複数のノードに含まれる第１のノードによって、かつ上記複数のノードに含まれる他の全てのノードによるより前に、第２のアンチエントロピー修復手順の開始準備ができていることを判断し；上記第２のアンチエントロピー修復手順に関連する修復スケジュールを生成し；上記修復スケジュールをデータストアに書き込んで、上記複数のノードに含まれる複数のノードにわたって上記第２のアンチエントロピー修復手順を開始するよう構成された、プロセッサとを備える。

【0108】

２０．上記プロセッサは更に、上記命令を実行したときに、上記複数のノードに含まれる第２のノードにおいて、ある個数の処理コアを、上記第２のアンチエントロピー修復手順に関連する修復を実施するために割り当て、上記処理コアの上記個数は最大で、上記第２のノード内で利用可能なプロセッサコアの個数の半分である、第１９項に記載の計算デバイス。

【0109】

請求項のうちのいずれかに記載の請求対象の要素のうちのいずれ、及び／又は本出願に記載のいずれの要素の、いずれの様式でのあらゆる全ての組み合わせは、本発明及び保護の企図された範囲内にある。

【0110】

様々な実施形態の説明は、例示を目的として提示されたものであり、網羅的なものであること、又は本開示の実施形態への限定を意図したものではない。本明細書に記載の実施形態の範囲及び精神から逸脱することなく、多数の修正及び変形が当業者には明らかであろう。

【0111】

本発明の実施形態の態様は、システム、方法、又はコンピュータプログラム製品として具現化できる。従って、本開示の態様は、完全にハードウェアである実施形態、完全にソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）である実施形態、又はソフトウェアの態様とハードウェアの態様と（これらは全て、本明細書では一般に「モジュール（ｍｏｄｕｌｅ）」若しくは「システム（ｓｙｓｔｅｍ）」と呼ばれる場合がある）を組み合わせた実施形態の形態を取ることができる。更に、本開示の態様は、コンピュータ可読プログラムコードが具現化されている１つ以上のコンピュータ可読媒体として具現化された、コンピュータプログラム製品の形態を取ることができる。

【0112】

１つ以上のコンピュータ可読媒体のいずれの組み合わせを利用してよい。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読ストレージ媒体であってよい。コンピュータ可読ストレージ媒体は、限定するものではないが例えば、電子、磁気、光学、電磁気、赤外線、又は半導体のシステム、装置、又はデバイス、あるいはこれらのいずれの好適な組み合わせであってよい。コンピュータ可読ストレージ媒体の更に具体的な例（非包括的なリスト）は、以下を含む：１つ以上の配線を含む電気的接続、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能かつプログラム可能な読み出し専用メモリ（ＥＰＲＯＭ若しくはフラッシュメモリ）、光ファイバ、ポータブルコンパクトディスク読み出し専用メモリ（ＣＤ‐ＲＯＭ）、光ストレージデバイス、磁気ストレージデバイス、又はこれらのいずれの好適な組み合わせ。本文書の文脈において、コンピュータ可読ストレージ媒体は、命令実行システム、装置若しくはデバイスによって又はこれらに関連して使用されるためのプログラムを内包又は保存できる、いずれの有形媒体であってよい。

【0113】

本開示の態様について、本開示の実施形態による方法、装置（システム）及びコンピュータプログラム製品のフローチャート図及び／又はブロック図を参照して上述した。これらのフローチャート図及び／又はブロック図の各ブロック、並びにこれらのフローチャート図及び／又はブロック図内のブロックの組み合わせは、コンピュータプログラム命令によって実装可能であることが理解されるだろう。これらのコンピュータプログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラマブルデータ処理装置に供給することにより、コンピュータ又は他のプログラマブルデータ処理装置によって実行された場合に上記フローチャート及び／又はブロック図の１つ以上のブロックで指定された機能／作用の実装を可能とするような機械を製造できる。このようなプロセッサは、限定するものではないが、汎用プロセッサ、専用プロセッサ、特定用途向けプロセッサ、又はフィールドプログラマブルゲートアレイであってよい。

【0114】

図面中のフローチャート及びブロック図は、本開示の様々な実施形態によるシステム、方法、及びコンピュータプログラム製品の可能な実装形態のアーキテクチャ、機能性、及び動作を図示している。これに関して、上記フローチャート又はブロック図中の各ブロックは、１つ以上の指定された論理機能を実装するための１つ以上の実行可能な命令を含む、モジュール、セグメント、又はコードの一部分を表すことができる。また、いくつかの代替実装形態では、ブロック内に記載された機能は、図面に記載された順序とは異なる順序で行われる場合があることにも留意されたい。例えば、関連する機能性に応じて、連続して示されている２つのブロックは、実際には略同時発生的に実行される場合があり、又はこれらのブロックが逆の順序で実行される場合もある。また、ブロック図及び／又はフローチャート図の各ブロック、並びにブロック図及び／又はフローチャート図中のブロックの組み合わせは、指定された機能若しくは作用を実施する専用のハードウェアベースのシステム、又は専用のハードウェアとコンピュータ命令との組み合わせによって実装できる。
以下、本発明の好ましい実施形態を項分け記載する。
実施形態１
コンピュータ実装型の方法であって、前記方法は：
複数のノードに含まれる第１のノードによって、かつ前記複数のノードに含まれる他の全てのノードによるよりも前に、第１のアンチエントロピー修復手順が終了したことを判断するステップ；
前記第１のノードによって、第２のアンチエントロピー修復手順の開始準備ができていることを判断するステップ；
前記第２のアンチエントロピー修復手順に関連する１つ以上の操作を実行するためのスケジュールを生成するステップ；及び
前記スケジュールを共有修復スケジュールデータ構造に書き込むことによって、前記第２のアンチエントロピー修復手順を、前記複数のノードに含まれる複数のノードにわたって開始するステップ
を含む、コンピュータ実装型の方法。
実施形態２
前記第２のアンチエントロピー修復手順の開始準備ができていることを判断する前記ステップは、現時点が、修復動作のために指定された特定の時間範囲内であることを判断するステップを含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態３
前記複数のノードに含まれる第２のノードによって、第３のアンチエントロピー修復手順の開始準備ができていることを判断するステップ；
前記第３のアンチエントロピー修復手順に関連する１つ以上の操作を実行するためのスケジュールを生成するステップ；及び
前記スケジュールを第２の共有修復スケジュールデータ構造に書き込んで、前記複数のノードに含まれる複数のノードにわたって前記第３のアンチエントロピー修復手順を開始するステップ
を更に含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態４
前記第２のアンチエントロピー修復手順はフルアンチエントロピー修復手順を含み、
前記第３のアンチエントロピー修復手順はインクリメンタルアンチエントロピー修復手順を含み、
前記第３のアンチエントロピー修復手順の開始準備ができていることを判断する前記ステップは、インクリメンタル修復を含む第４のアンチエントロピー修復手順が終了したことを判断するステップを含む、実施形態３に記載のコンピュータ実装型の方法。
実施形態５
前記複数のノードに含まれる第２のノードによって、前記第２のアンチエントロピー修復手順が進行中であることを判断するステップ；
前記第２のアンチエントロピー修復手順が、修復について次の順番であることを判断するステップ；及び
前記第２のノード上に存在する少なくとも１つの整合性を失ったデータパーティションを修復するステップ
を更に含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態６
前記複数のノードに含まれる第２のノードによって、前記第２のアンチエントロピー修復手順が進行中であることを判断するステップ；
前記第２のノードが、前記第２のアンチエントロピー修復手順に関連する修復を現在実施している前記複数のノードに含まれる他の全てのノードから独立していることを判断するステップ；及び
前記第２のノード上に存在する少なくとも１つの整合性を失ったデータパーティションを修復するステップ
を更に含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態７
前記複数のノードに含まれる第２のノードによって、前記第２のアンチエントロピー修復手順が進行中であることを判断するステップ；
前記第２のノードが、前記第２のアンチエントロピー修復手順に関連する修復を実施したことを判断するステップ；
前記第２のノードと相互依存関係にある、前記複数のノードに含まれる他の全てのノードが、前記第２のアンチエントロピー修復手順に関連する修復を実施したことを判断するステップ；及び
前記第２のノードによって、前記第２のアンチエントロピー修復手順に関連する修復後手順を実施するステップ
を更に含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態８
前記修復後手順を実施する前記ステップは、前記第２のアンチエントロピー修復手順の完了後には不要であるパーティションを削除するステップを含む、実施形態７に記載のコンピュータ実装型の方法。
実施形態９
前記修復後手順を実施する前記ステップは、前記第２のノードに関連する１つ以上のパーティションに対して圧縮操作を実施して、前記１つ以上のパーティションへのアクセス時のレイテンシを低減するステップを含む、実施形態７に記載のコンピュータ実装型の方法。
実施形態１０
前記修復後手順を実施する前記ステップは、前記第２のノードが前記第２のアンチエントロピー修復手順に関連する前記修復を実施したことを示すメッセージを、監視アプリケーションに送信するステップを含む、実施形態７に記載のコンピュータ実装型の方法。
実施形態１１
前記第２のアンチエントロピー修復手順に関連するパーティションの個数が閾値レベルを超えることを判断するステップ；及び
前記第２のアンチエントロピー修復手順に関連する作業を複数の部分範囲に分割するステップ
を更に含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態１２
前記第２のアンチエントロピー修復手順に関連する１つ以上のパーティションのサイズが閾値レベルを超えることを判断するステップ；及び
前記第２のアンチエントロピー修復手順に関連する作業を複数の部分範囲に分割するステップ
を更に含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態１３
前記第２のアンチエントロピー修復手順のための完了時間が閾値レベルを超えることを判断するステップ；及び
前記第２のアンチエントロピー修復手順に関連する作業を、前記完了時間に基づいて、複数の部分範囲に分割するステップ
を更に含む、実施形態１に記載のコンピュータ実装型の方法。
実施形態１４
１つ以上の非一時的コンピュータ可読ストレージ媒体であって、前記非一時的コンピュータ可読ストレージ媒体は、命令を含み、前記命令は、１つ以上のプロセッサによって実行された場合に前記プロセッサ：
第１のアンチエントロピー修復手順が終了したことを判断するステップ；
複数のノードに含まれる第１のノードによって、かつ前記複数のノードに含まれる他の全てのノードによるより前に、第２のアンチエントロピー修復手順の開始準備ができていることを判断するステップ；
前記第２のアンチエントロピー修復手順に関連する動作を実行するためのスケジュールを生成するステップ；及び
前記スケジュールを共有修復スケジュールデータ構造に書き込んで、前記複数のノードに含まれる複数のノードにわたって前記第２のアンチエントロピー修復手順を開始するステップ
を実施させる、１つ以上の非一時的コンピュータ可読ストレージ媒体。
実施形態１５
前記第２のアンチエントロピー修復手順の開始準備ができていることを判断する前記ステップは、現時点が、修復動作のために指定された特定の時間範囲内であることを判断するステップを含む、実施形態１４に記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。
実施形態１６
前記複数のノードに含まれる各ノードは、前記第２のアンチエントロピー修復手順に関連する修復を順次実施する、実施形態１４に記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。
実施形態１７
前記複数のノードに含まれる第１のノードのサブセットに含まれる各ノードは、前記第２のアンチエントロピー修復手順に関連する修復を互いに並列に実施し；
前記複数のノードに含まれる第２のノードのサブセットに含まれる各ノードは、前記第２のアンチエントロピー修復手順に関連する修復を互いに並列に実施し；
前記第１のノードのサブセットに含まれる前記ノードは、前記第２のノードのサブセットに含まれる前記ノードに対して、前記第２のアンチエントロピー修復手順に関連する前記修復を順次実施する、実施形態１４に記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。
実施形態１８
前記複数のノードに含まれる各ノードは、前記第２のアンチエントロピー修復手順に関連する修復を互いに並列に実施する、実施形態１４に記載の１つ以上の非一時的コンピュータ可読ストレージ媒体。
実施形態１９
計算デバイスであって、前記計算デバイスは：
命令を含むメモリ；及び
前記メモリに結合されたプロセッサであって、前記命令を実行したときに：
第１のアンチエントロピー修復手順が終了したことを判断し；
複数のノードに含まれる第１のノードによって、かつ前記複数のノードに含まれる他の全てのノードによるより前に、第２のアンチエントロピー修復手順の開始準備ができていることを判断し；
前記第２のアンチエントロピー修復手順に関連する修復スケジュールを生成し；
前記修復スケジュールをデータストアに書き込んで、前記複数のノードに含まれる複数のノードにわたって前記第２のアンチエントロピー修復手順を開始する
よう構成された、プロセッサ
を備える、計算デバイス。
実施形態２０
前記プロセッサは更に、前記命令を実行したときに、前記複数のノードに含まれる第２のノードにおいて、ある個数の処理コアを、前記第２のアンチエントロピー修復手順に関連する修復を実施するために割り当て、前記処理コアの前記個数は最大で、前記第２のノード内で利用可能なプロセッサコアの個数の半分である、実施形態１９に記載の計算デバイス。

【0115】

以上は、本開示の実施形態を対象としているが、本開示の基本的な範囲から逸脱することなく、本開示の他の更なる実施形態を考案することもでき、本開示の範囲は以下の請求項によって決定される。

【符号の説明】

【0116】

１００ ネットワークインフラストラクチャ
１０５ 通信ネットワーク
１１０ コンテンツサーバ
１１５ エンドポイントデバイス
１２０ 制御サーバ
１４０ クラスタ
１３０ フィルソース
２０４、３０４、４１０ プロセッサ
２０６、３０６ システムディスク
２０８、３０８、４１４ 入出力（Ｉ／Ｏ）デバイスインタフェース
２１０、３１０、４１８ ネットワークインタフェース
２１２、３１２、４２２ 相互接続
２１４、３１４ システムメモリ
２１６、３１６ Ｉ／Ｏデバイス
２１７ サーバアプリケーション
２１８ ファイル
２１９ 修復アプリケーション
２２１ データストア
３１７ 制御アプリケーション
４１２ グラフィックスサブシステム
４１６ マスストレージユニット
４３０ メモリサブシステム
４５０ ディスプレイデバイス
４５２ ユーザＩ／Ｏデバイス

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】