特許 6479020 分散ストレージシステムにおけるオブジェクトの階層チャンキング

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

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

(11)【特許番号】6479020

(24)【登録日】2019年2月15日

(45)【発行日】2019年3月6日

(54)【発明の名称】分散ストレージシステムにおけるオブジェクトの階層チャンキング

(51)【国際特許分類】

   G06F 12/00 20060101AFI20190225BHJP

【ＦＩ】

   G06F12/00 545A

   G06F12/00 531M

   G06F12/00 520E

【請求項の数】19

【全頁数】34

(21)【出願番号】特願2016-543054(P2016-543054)

(86)(22)【出願日】2014年12月24日

(65)【公表番号】特表2017-500670(P2017-500670A)

(43)【公表日】2017年1月5日

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

(87)【国際公開番号】WO2015100416

(87)【国際公開日】20150702

【審査請求日】2017年12月20日

(31)【優先権主張番号】14/142,706

(32)【優先日】2013年12月27日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502208397

【氏名又は名称】グーグル エルエルシー

(74)【代理人】

【識別番号】110001195

【氏名又は名称】特許業務法人深見特許事務所

(72)【発明者】

【氏名】ケッセルマン，アレグザンダー

(72)【発明者】

【氏名】オレイリー，マイケル

(72)【発明者】

【氏名】ダツアシビリ，ジョージ

(72)【発明者】

【氏名】ドロビチェフ，アレクサンドル

【審査官】 漆原 孝治

(56)【参考文献】

【文献】 特開２０１１−１９７９７７（ＪＰ，Ａ）

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

【文献】 再公表特許第２０１２／１２７９８８（ＪＰ，Ａ１）

【文献】 国際公開第２０１２／１５８６５４（ＷＯ，Ａ１）

【文献】 特表２０１２−５２４９４３（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １２／００

(57)【特許請求の範囲】

【請求項1】

分散ストレージシステムにおいてオブジェクトレプリカの配置を管理するための方法であって、
１つ以上のプロセッサと、前記１つ以上のプロセッサによる実行のための１つ以上のプログラムを格納するメモリとを有する、前記分散ストレージシステムの第１のインスタンスにおいて、
第１の配置ポリシーに関連付けられる第１のオブジェクトを受け取ることを含み、前記第１の配置ポリシーは、前記第１のオブジェクトのレプリカが前記分散ストレージシステムにおいてどこに格納されるかについて基準を特定し、前記方法はさらに、
前記オブジェクトを複数のオブジェクトチャンクに分割し、前記複数のオブジェクトチャンクの第１のオブジェクトチャンクを複数のブロックへ分割することと、
関連付けられる配置ポリシーが前記第１の配置ポリシーにマッチする第１のジャーナルに前記複数のブロックを格納することと、
前記第１のオブジェクトについてグローバルメタデータを格納することとを含み、前記グローバルメタデータは前記複数のオブジェクトチャンクのリストを含み、前記リストは前記オブジェクトチャンクの各々についてそれぞれの識別子を含み、前記方法はさらに、
前記第１のオブジェクトチャンクについてローカルメタデータを格納することを含み、前記ローカルメタデータは、前記複数のブロックの各ブロックを識別するブロックリストを含み、前記ローカルメタデータは前記第１のジャーナルに関連付けられ、前記方法はさらに、
前記第１の配置ポリシーに従って前記第１のジャーナルを前記分散ストレージシステムの第２のインスタンスにレプリケートすることを含み、前記グローバルメタデータは当該レプリケーションを反映するために更新され、前記ローカルメタデータは前記レプリケーションによって変更されない、方法。

【請求項2】

前記グローバルメタデータは、各オブジェクトチャンクがブロックまたはブロックのリストかどうかを特定するフィールドを含み、第２のオブジェクトチャンクはブロックであり、前記第１のオブジェクトチャンクはブロックのリストである、請求項１に記載の方法。

【請求項3】

前記グローバルメタデータは、各オブジェクトチャンクがどのジャーナルに格納されるかを特定し、各それぞれのジャーナルレプリカは、前記それぞれのジャーナルレプリカに格納される各ブロックの位置を特定するブロックインデックスを含む、請求項１または２に記載の方法。

【請求項4】

前記第１のインスタンスにおいて、
第１のクローズドジャーナルのレプリカを選択することと、
前記グローバルメタデータに参照が存在しない前記レプリカに格納される１つ以上のオブジェクトチャンクを識別することと、
前記レプリカをコンパクト化し、これにより前記レプリカに格納される前記ブロックを連続するストレージに統合することとをさらに含む、請求項１〜３のいずれか１項に記載の方法。

【請求項5】

前記分散ストレージシステムは、異なる地理的位置にて複数のインスタンスを有する、請求項１〜４のいずれか１項に記載の方法。

【請求項6】

各オブジェクトチャンクについてのデータが暗号化され、各オブジェクトチャンクについての復号化キーが前記グローバルメタデータに格納され、前記方法はさらに、前記グローバルメタデータから対応する復号化キーを削除することによって、オブジェクトチャンクを事実上削除し、これにより、前記オブジェクトについてのデータをアクセス不能にすることを含む、請求項１〜５のいずれか１項に記載の方法。

【請求項7】

分散ストレージシステムにおいてオブジェクトレプリカの配置を管理するための方法であって、
１つ以上のプロセッサと、前記１つ以上のプロセッサによる実行のための１つ以上のプログラムを格納するメモリとを有する、前記分散ストレージシステムの第１のインスタンスにおいて、
オブジェクトチャンクの格納のために１つ以上のジャーナルをオープンにすることを含み、各それぞれのジャーナルは単一のそれぞれの配置ポリシーに関連付けられ、前記方法はさらに、
少なくとも第１のオブジェクトチャンクを含む第１のオブジェクトを受け取ることを含み、前記第１のオブジェクトは第１の配置ポリシーに関連付けられ、前記第１のオブジェクトチャンクは第１の複数のブロックを含み、前記方法はさらに、
関連付けられる配置ポリシーが前記第１の配置ポリシーとマッチする第１のジャーナルに前記第１の複数のブロックを格納することを含み、前記第１のジャーナルは、配置ポリシーが前記第１の配置ポリシーとマッチするオブジェクトについてのブロックのみを格納し、前記方法はさらに、
前記第１のオブジェクトについてのグローバルメタデータを格納することを含み、前記グローバルメタデータは、前記第１のオブジェクトに対応するオブジェクトチャンクの第１のリストを含み、前記第１のリストは前記第１のオブジェクトチャンクの識別子を含み、前記方法はさらに、
前記第１のオブジェクトチャンクについてローカルメタデータを格納することを含み、前記ローカルメタデータは、前記第１の複数のブロックの各ブロックを識別するブロックリストを含み、前記ローカルメタデータは前記第１のジャーナルに関連付けられ、前記方法はさらに、
前記第１のジャーナルについて、関連付けられる配置ポリシーが前記第１の配置ポリシーとマッチする第１の複数のオブジェクトについての前記受け取るステップおよび格納するステップを、第１の終了条件が発生するまで繰り返すことと、
前記第１の終了条件が発生した後、前記第１のジャーナルをクローズし、これにより、如何なる付加的なブロックも前記第１のジャーナルに格納されるのを防止することと、
前記第１の配置ポリシーに従って前記分散ストレージシステムの第２のインスタンスへ前記第１のジャーナルをレプリケートすることとを含み、前記グローバルメタデータは当該レプリケーションを反映するよう更新され、前記ローカルメタデータは前記レプリケーションによって変更されない、方法。

【請求項8】

各オブジェクトチャンクは１つ以上のブロックを含む、請求項７に記載の方法。

【請求項9】

前記グローバルメタデータは、各オブジェクトチャンクがブロックまたはブロックのリストであるかどうかを特定するフィールドを含む、請求項７または８に記載の方法。

【請求項10】

第２のオブジェクトチャンクはブロックであり、前記第１のオブジェクトチャンクはブロックのリストである、請求項９に記載の方法。

【請求項11】

前記第１のオブジェクトは、前記第１のオブジェクトチャンクとは異なる第２のオブジェクトチャンクを含む２つ以上のオブジェクトチャンクを含み、前記第２のオブジェクトチャンクは、関連付けられる配置ポリシーが前記第１の配置ポリシーとマッチする、前記第１のジャーナルとは異なる第２のジャーナルに格納される、請求項７〜１０のいずれか１項に記載の方法。

【請求項12】

前記グローバルメタデータは、各オブジェクトチャンクがどのジャーナルに格納されるかを特定し、各それぞれのジャーナルレプリカは、前記それぞれのジャーナルレプリカに格納される各ブロックの位置を特定するブロックインデックスを含む、請求項７〜１１のいずれか１項に記載の方法。

【請求項13】

前記第１のインスタンスにおいて、
第１のクローズドジャーナルのレプリカを選択することと、
前記グローバルメタデータに参照が存在しない前記レプリカに格納される１つ以上のオブジェクトチャンクを識別することと、
前記レプリカをコンパクト化し、これにより前記レプリカに格納される前記ブロックを連続するストレージに統合することとをさらに含む、請求項７〜１２のいずれか１項に記載の方法。

【請求項14】

各配置ポリシーは、対象数のオブジェクトレプリカと、オブジェクトレプリカについての位置の対象セットとを特定する、請求項７〜１３のいずれか１項に記載の方法。

【請求項15】

前記分散ストレージシステムは、異なる地理的位置にて複数のインスタンスを有する、請求項７〜１４のいずれか１項に記載の方法。

【請求項16】

各オブジェクトチャンクについてのデータが暗号化され、各オブジェクトチャンクについての復号化キーが前記グローバルメタデータに格納される、請求項７〜１５のいずれか１項に記載の方法。

【請求項17】

前記グローバルメタデータから対応する復号化キーを削除することによって、オブジェクトチャンクを事実上削除し、これにより、前記オブジェクトについてのデータをアクセス不能にすることをさらに含む、請求項１６に記載の方法。

【請求項18】

複数のインスタンスを有する分散ストレージシステムにおけるオブジェクトレプリカの配置を管理するためのコンピュータシステムであって、各それぞれのインスタンスは、
１つ以上のプロセッサと、
メモリと、
前記メモリに格納される１つ以上のプログラムとを含み、前記１つ以上のプログラムは、請求項１〜１７のいずれか１項に記載の方法を実行するために前記１つ以上のプロセッサによって実行可能である命令を含む、コンピュータシステム。

【請求項19】

複数のインスタンスを有する分散ストレージシステムにおいてオブジェクトレプリカの配置を管理するために格納されるプログラムを有するコンピュータ読取可能プログラムであって、各それぞれのインスタンスは、１つ以上のプロセッサとメモリとを含み、前記１つ以上のプログラムは、請求項１〜１７のいずれか１項に記載の方法を実行するために前記１つ以上のプロセッサによって実行可能である命令を含む、コンピュータ読取可能プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

技術分野
開示される実現例は一般に、分散ストレージシステムに関し、より具体的には、オブジェクトをチャンクに分割し、当該チャンクを階層的に格納することに関する。

【背景技術】

【0002】

背景
大規模データストレージは、中央サービスアーキテクチャから分散ストレージシステムにシフトしている。コモディティのコンピュータから構築される分散ストレージシステムは、モノリシックディスクアレイと比較して数分の１のコストで、高い性能（high performance）、可用性（availability）およびスケーラビリティ（scalability）を提供することが可能である。データは、異なる地理的位置における分散ストレージシステムの複数のインスタンスにわたってレプリケート（replicate）され、これにより可用性を増加するとともにクライアントからのネットワーク距離を低減する。

【0003】

分散ストレージシステムにおいて、オブジェクトは、制約に基づいて、分散ストレージシステムのさまざまなインスタンスに動的に配置される（すなわち当該インスタンスにおいて作成され、当該インスタンスから削除され、および／または、当該インスタンスに移動される）。何兆個ものオブジェクトと何ペタバイトものデータとを格納するとともにこの地球にわたって何十ものデータセンタを含むプラネットワイドな分散ストレージシステムにおける制約に従うオブジェクトを効率的に配置するための既存の技術はほとんど存在しない。

【0004】

新しい視覚化アプリケーション、マルチメディアアプリケーションおよび他のデータ集中的なアプリケーションは、何百ギガバイト以上であり得る非常に大きいオブジェクトを使用する。そのような非常に大きいオブジェクトを管理することにより、分散ストレージシステムについてさらなる複雑性が作り出されている。まず、分散ストレージシステムへそのようなオブジェクトをアップロードすることは典型的にストリーミングモードで行なわれ、オブジェクトをチャンクに分割し、各チャンクを個々に書き込む。これにより、アップロードについて長い遅延が課され得、これは、潜在的なクライアント障害およびサーバ障害によって悪化する。さらに、よりよい効率性のために、チャンクは、より大きなシャード（shard）になるように集合され得る。本願明細書において、「シャード」および「ジャーナル（journal）」という用語は、交換可能に使用され得る。結果として、クライアントがある時に利用可能な任意のクラスタに接続することを可能にする大規模システムの必要性によって前進するストレージ産業にとって、大きなオブジェクトの効率的なアップロードは、ますます重要になっている。さらに、単一のオブジェクトについてのメタデータのボリューム（たとえば１００ギガバイトのファイルについて２５０００個のチャンクがあり、各チャンクは４メガバイトである）では、レプリケーション（replication）およびコンパクション（compaction）はあまり効率的でない。

【発明の概要】

【課題を解決するための手段】

【0005】

概要
開示される実現例は、大きいオブジェクトのアップロードを複数のストレージ位置に同時に分散する。本願明細書において使用されるように、ストレージ位置は、「シャード」、「集合シャード」または「ジャーナル」と称される。このスキームは、大きいオブジェクトを複数のチャンクへ分割することにより実現され、当該複数のチャンクの各々は、（異なる地理的位置にあってもよい）異なるストレージクラスタにアップロードされ得る。（たとえばシャードが「いっぱい」であるか、または、シャードが格納されるインスタンスがダウンしたので）シャードがアップロードの間に利用不可能になると、クライアントは、異なるクラスタに存在し得る新しいシャードにスイッチングする。このスキームは、ひとたびスタートされると、同じシャードにとどまることを必要としない。終了したオブジェクトは、チャンク参照の順序づけられたリストによって表わされる。

【0006】

いくつかのスキームにおいて、チャンクは格納の基本単位であり、各チャンクの位置はグローバルメタデータに格納される。非常に大きいオブジェクトの場合、このスキームでは、単一のオブジェクトについて、グローバルレベルでかなりの量のメタデータが格納されることになる。したがって、いくつかの実現例は、各オブジェクトについて格納されるグローバルメタデータの量を低減する階層チャンキングスキーム（hierarchical chunking scheme）を使用する。階層的な実現例において、「チャンク」という用語は、グローバルレベルに格納される対応するメタデータを有するトップレベルの分割を識別するために使用される。これらの実現例では、「ブロック」という用語は、実際の格納の基本単位を識別するために使用される（たとえば２メガバイトまたは８メガバイト）。ブロックは、各シャードについてローカルで管理される。非階層的システムにおいて、格納の基本単位は、グローバルメタデータが格納される基本単位であるので、「チャンク」という単一の用語は、両方のコンセプトを識別するために使用され得る。

【0007】

階層チャンキングは、複数の態様で実現され得る。いくつかの実現例では、１つのブロックのみが存在する場合でも、各チャンクはブロックのリストを含む。これらの実現例では、チャンクに対応するデータのルックアップについての付加的な階層レベルが常に存在する。他の実現例は、大きなチャンクについて必要とされる場合にのみ階層が存在するように、ハイブリッドスキームを使用する。そのようなハイブリッド実現例では、小さなオブジェクトは、単一のブロックに対応する単一のチャンクを含み得る。他方、より大きなオブジェクトについては、各チャンクはブロックのリストである。

【0008】

開示される階層スキームは、グローバルメタデータの量を低減し、これにより、オブジェクトを管理するコストまたは１つのストレージクラスタから別のストレージクラスタにオブジェクトを移動するコストを低減する。オブジェクトチャンクはグローバルレベルにて管理される一方、チャンク内のブロックは、オブジェクトメタデータが典型的に１つのシャード当たり１つのチャンク参照のみを含むように、ローカルシャードレベルにて管理される。

【0009】

いくつかの実現例では、アップロードプロセスは、（１）アップロードのために利用可能なシャードを発見するステップと、（２）シャードが利用不可能（たとえばいっぱい）になるか、または、データがもはや存在しなくなるまで現在のシャードにデータを書き込むステップと、（３）チャンクの順序付けられたリストに現在のチャンク参照を追加するステップと、（４）オブジェクトアップロードが終わると、オブジェクトを終了させるステップと、そうでなければ、（５）オブジェクトの残りについてステップ（１）の開始を繰り返すステップとに従う。

【0010】

いくつかの実現例において、ストレージからオブジェクトを読み出すことは、（１）所望のオブジェクトについて、チャンク参照（少なくとも１つは常に存在する）のセットを見つけるステップと、（２）チャンク参照に基づいてシャードの位置を見つけるステップと、（３）チャンク識別子およびローカルシャードメタデータを使用して、シャード位置からデータを読み出すステップと、（４）各チャンク参照についてステップ２および３を繰り返すステップとに従う。

【0011】

たとえば、オブジェクトアップロードがシャード１にデータを書き込むことにより開始され、シャード１がいっぱいになるとシャード２にスイッチングするとする。（２つのシャード１およびシャード２は、同じまたは異なるインスタンスに存在し得る。）（グローバルである）オブジェクトメタデータは、２つのチャンク参照からなる一方、各シャードは各チャンクについてのブロックのローカルリストを管理する。たとえば、各シャードは、オブジェクトについて複数のブロックを格納し得る。この場合、ストレージは完全に階層的である。すなわち、オブジェクトはチャンクへ分割され、各チャンクはブロックへ分割される。他の実現例では、チャンクのうちの１つは、複数のブロックに分割され得る（そのようなチャンクは時に「スーパーチャンク」と称される）一方、別のチャンクは単一のブロックからなり得る。後者の場合において、チャンク識別子はブロック識別子であり得る。

【0012】

シャード１およびシャード２は互いから独立しているので、それらのレプリカは異なるインスタンスで格納され得る。たとえば、シャード１はインスタンス１およびインスタンス２に格納され得、シャード２はインスタンス１およびインスタンス３に格納され得る。

【0013】

この開示された方法は実質的に、アップロードサービスの可用性およびストレージ効率の両方を向上させる。この方法は、（たとえばインスタンスが大きいオブジェクトのアップロードの間にダウンした際の）再開可能なアップロードと、（たとえばシャードがいっぱいになった場合での）アップロードの最中における新しいシャードへのスイッチングとをサポートする。さらに、この方法は、複数のシャードに同時に書き込むことをサポートし、これにより、非常に大きいオブジェクトについて性能を有意に向上させ得る。いくつかの実現例では、単一のオブジェクトについてのデータが、異なるインスタンスにおいて同時に２つ以上の異なるシャードに書き込まれ、同時に同じインスタンスにおいて２つ以上のシャードに書き込まれ、また、単一のジャーナル内でも、２つ以上のプロセススレッドが、単一のジャーナルに異なるデータブロックを同時に書き込み得る。もちろん、分散アップロードは、利用可能なリソースによって制限される。分散ストレージシステムは、オブジェクトを同時にアップロードする多くの異なるクライアントを有するので、１つのクライアントからの単一の非常に大きいオブジェクトが、利用可能なリソースを過度に消費することは許可されない。

【0014】

いくつかの実現例に従うと、分散ストレージシステムにおけるオブジェクトレプリカの配置を管理するための方法は、分散ストレージシステムの第１のインスタンスにおいて実行される。第１のインスタンスは１つ以上のサーバを有しており、当該１つ以上のサーバの各々は１つ以上のプロセッサおよびメモリを有する。メモリは、１つ以上のプロセッサによる実行のための１つ以上のプログラムを格納する。第１のインスタンスは、第１の配置ポリシーに関連付けられる第１のオブジェクトを受け取る。第１の配置ポリシーは、第１のオブジェクトのレプリカが分散ストレージシステムにおいてどこに格納されるかについて基準を特定する。いくつかの実現例では、各配置ポリシーは、対象数のオブジェクトレプリカと、それらのレプリカについての対象位置とを特定する。第１のインスタンスは、オブジェクトを複数のオブジェクトチャンクに分割し、複数のオブジェクトチャンクの第１のオブジェクトチャンクを複数のブロックへ分割する。第１のインスタンスは、関連付けられる配置ポリシーが第１の配置ポリシーとマッチする第１のジャーナルに複数のブロックを格納する。第１のインスタンスは、第１のオブジェクトについてグローバルメタデータを格納し、当該グローバルメタデータは、複数のオブジェクトチャンクのリストを含む。リストは、オブジェクトチャンクの各々についてのそれぞれの識別子を含む。第１のインスタンスは、第１のオブジェクトチャンクについてローカルメタデータを格納し、当該ローカルメタデータは、複数のブロックの各ブロックを識別するブロックリストを含む。ローカルメタデータは第１のジャーナルに関連付けられる。第１のジャーナルはその後、第１の配置ポリシーに従って、分散ストレージシステムの第２のインスタンスにレプリケートされる。グローバルメタデータはレプリケーションを反映するために更新され、ローカルメタデータはレプリケーションによって変更されない。

【0015】

いくつかの実現例に従うと、分散ストレージシステムにおけるオブジェクトレプリカの配置を管理するための方法は、分散ストレージシステムの第１のインスタンスにおいて実行される。第１のインスタンスは、各々が１つ以上のプロセッサおよびメモリを有する１つ以上のサーバを有する。メモリは、１つ以上のプロセッサによる実行のための１つ以上のプログラムを格納する。１つ以上のジャーナルがオブジェクトチャンクの格納のためにオープンにされる。各ジャーナルは、単一の配置ポリシーに関連付けられる。いくつかの実現例では、各配置ポリシーは、対象数のオブジェクトレプリカと、それらのレプリカについての対象位置とを特定する。第１のインスタンスは、少なくとも第１のオブジェクトチャンクを含む第１のオブジェクトを受け取る。第１のオブジェクトは第１の配置ポリシーに関連付けられる。第１のオブジェクトチャンクは第１の複数のブロックを含む。第１のインスタンスは、関連付けられる配置ポリシーが第１の配置ポリシーとマッチする第１のジャーナルに第１の複数のブロックを格納する。第１のジャーナルは、配置ポリシーが第１の配置ポリシーとマッチするオブジェクトについてのブロックのみを格納する。第１のインスタンスは、第１のオブジェクトについてグローバルメタデータを格納し、グローバルメタデータは、第１のオブジェクトに対応するオブジェクトチャンクの第１のリストを含む。第１のリストは、第１のオブジェクトチャンクの識別子を含む。第１のインスタンスはさらに、第１のオブジェクトチャンクについてローカルメタデータを格納し、ローカルメタデータは、第１の複数のブロックの各ブロックを識別するブロックリストを含む。ローカルメタデータは第１のジャーナルに関連付けられる。第１のジャーナルの場合、関連付けられる配置ポリシーが第１の配置ポリシーとマッチする第１の複数のオブジェクトについて受け取るステップおよび格納するステップが、第１の終了条件が発生するまで繰り返される。いくつかの実現例では、時間の予め規定されたスパンの後、または、第１のジャーナルが予め規定されたサイズしきい値を越えた後に、第１の終了条件が発生する。第１の終了条件が発生した後、第１のジャーナルはクローズされ、これにより、如何なる付加的なブロックも第１のジャーナルに格納されるのを防止する。その後、第１のジャーナルは、第１の配置ポリシーに従って、分散ストレージシステムの第２のインスタンスにレプリケートされる。グローバルメタデータはレプリケーションを反映するために更新され、ローカルメタデータはレプリケーションによって変更されない。

【図面の簡単な説明】

【0016】

【図1】いくつかの実現例に従った、分散ストレージシステムの概念図である。

【図2】いくつかの実現例に従った、分散ストレージシステムの要素を示すブロック図である。

【図3】いくつかの実現例に従ったサーバのブロック図である。

【図4】いくつかの実現例に従ったインスタンスサーバのブロック図である。

【図5】いくつかの実現例に従った、オブジェクトチャンクの格納のためのジャーナルの使用を示す図である。

【図6】いくつかの実現例が新しいオブジェクトの格納をどのように管理するかを示す図である。

【図7】いくつかの実現例に従ったオープンジャーナルの構造を示す図である。

【図8】いくつかの実現例に従って、ジャーナルが１つのインスタンスから別のインスタンスにレプリケートされる場合、オブジェクトメタデータおよびジャーナルメタデータに何が起こるかを示す図である。

【図9A】いくつかの実現例に従った分散ストレージシステムにおけるオブジェクトレプリカの配置を管理する方法を示す図である。

【図9B】いくつかの実現例に従った分散ストレージシステムにおけるオブジェクトレプリカの配置を管理する方法を示す図である。

【図9C】いくつかの実現例に従った分散ストレージシステムにおけるオブジェクトレプリカの配置を管理する方法を示す図である。

【図10A】いくつかの実現例に従った、どのようにオブジェクトチャンクがブロックへさらに分割され得るかを示す図である。

【図10B】いくつかの実現例に従った、どのようにオブジェクトチャンクがブロックへさらに分割され得るかを示す図である。

【図11A】いくつかの実現例に従った、分散ストレージシステムにおけるオブジェクトレプリカの配置を管理する代替的な方法を示す図である。

【図11B】いくつかの実現例に従った、分散ストレージシステムにおけるオブジェクトレプリカの配置を管理する代替的な方法を示す図である。

【図11C】いくつかの実現例に従った、分散ストレージシステムにおけるオブジェクトレプリカの配置を管理する代替的な方法を示す図である。

【図11D】いくつかの実現例に従った、分散ストレージシステムにおけるオブジェクトレプリカの配置を管理する代替的な方法を示す図である。

【図12】いくつかの実現例に従った、部分的に階層的な分散ストレージシステムにおけるチャンクについての格納を示す図である。

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

【0017】

図面を通じて、同様の参照番号は対応する部分を指す。
実現例の説明
分散ストレージシステムにおいてオブジェクトの配置を管理するための技術について論じる前に、これらの技術が使用され得る例示的なシステムを提示することは有益である。

【0018】

分散ストレージシステムの概略
図１に示されるように、開示された実現例は分散ストレージシステムを記載する。地球１００上のさまざまな位置に、複数のインスタンス１０２−１、１０２−２、…、１０２−Ｎが存在しており、ネットワーク通信リンク１０４−１、１０４−２、…１０４−Ｍによって接続されている。なお、この明細書において、「インスタンス」は「ストレージ位置」とも称される。また、１つ以上のインスタンス（ストレージ位置）が特定の物理的位置（たとえばビルディング、互いから所定の距離内のビルディングのセットなど）に位置してもよい。いくつかの実現例において、インスタンス（たとえばインスタンス１０２−１）は、データセンタに対応する。いくつかの実現例において、複数のインスタンスは、同じデータセンタに物理的に位置する。単一の実現例は、異なる地理的位置にある個々のインスタンスと、インスタンスの１つ以上のクラスタとの両方を有し得、各クラスタは、複数のインスタンスを含み、各クラスタ内のインスタンスは単一の地理的位置に存在する。

【0019】

図１の概念図は、特定の数のネットワーク通信リンク１０４−１などを示すが、典型的な実現例は、それより多いまたは少ないネットワーク通信リンクを有してもよい。いくつかの実現例において、インスタンスの同じ対同士の間に２つ以上のネットワーク通信リンクが存在する。たとえば、ネットワーク通信リンク１０４−５および１０４−６は、インスタンス１０２−２とインスタンス１０２−６との間のネットワーク接続を提供する。いくつかの実現例において、ネットワーク通信リンクは光ファイバーケーブルを含む。いくつかの実現例において、ネットワーク通信リンクのうちのいくつかは、マイクロ波のような無線技術を使用する。いくつかの実現例において、各ネットワーク通信リンクは、特定の帯域幅、および／または、その帯域幅の使用についての特定のコストを有する。いくつかの実現例において、ネットワーク通信リンクのうち１つ以上にわたるデータ転送に関して、スループットレート、可用性の時間、リンクの信頼性などを含む統計が維持される。典型的に、各インスタンスは、データストアおよび関連するデータベースを有しており、タスクのすべてを実行するためにサーバコンピュータ（図４に示されるような「インスタンスサーバ」）のファーム（farm）を利用する。いくつかの実現例において、分散ストレージシステムの１つ以上のインスタンスは限定された機能を有する。たとえば、限定された機能は、他のインスタンス同士の間のデータ送信のためのリピータ（repeater）として動作することを含み得る。なお、限定された機能のインスタンスは、データストアのうちのいずれかを含んでもよいし、含まなくてもよい。

【0020】

図２は、いくつかの実現例に従った、分散ストレージシステム２００の要素を示すブロック図である。分散ストレージシステム２００は、インスタンス１０２−１、１０２−２、１０２−３、１０２−４、…、１０２−Ｎを含む。それぞれのインスタンス１０２−１は、インスタンス同士間でオブジェクトチャンク２３８をレプリケートするレプリケーションモジュール２２０を含む。いくつかの実現例において、オブジェクトチャンク２３８は、それぞれのインスタンス１０２−１のデータストア２２４に格納される。図６に示されるように、各オブジェクトチャンク２３８は、オブジェクト２２６、または、オブジェクト２２６の部分を含む。データストア２２４は、オブジェクトを格納することが可能である分散データベース、ファイルシステム、テープバックアップ、および、任意の他のタイプのストレージシステムまたはデバイスを含み得る。いくつかの実現例において、オブジェクト２２６またはジャーナル２３０をレプリケートするために、レプリケーションモジュール２２０は、１つ以上のレプリケーションキュー２２２−１、２２２−２、…、２２２−Ｌを使用する。レプリケートされるべきオブジェクトまたはジャーナルについてのレプリケーション要求がレプリケーションキュー２２２に配置され、リソース（たとえば帯域幅）が利用可能な場合、オブジェクトまたはジャーナルがレプリケートされる。いくつかの実現例において、レプリケーションキュー２２２におけるレプリケーション要求は、割り当てられたプライオリティを有しており、帯域幅が利用可能になると、最も高いプライオリティのレプリケーション要求がレプリケートされる。

【0021】

いくつかの実現例において、バックグラウンドレプリケーションプロセスは、配置ポリシー２１２、ならびに、統計サーバ２０８によって提供されるアクセスデータ２１０および／またはグローバル状態２１１に基づき、オブジェクトまたはジャーナルのコピーを作成および削除する。配置ポリシー２１２は、オブジェクトのどれだけ多くのコピーが所望であるか、どこに当該コピーが存在するべきであるか、および、どのタイプのデータストアに当該データが保存されるべきであるかを特定している。統計サーバ２０８によって提供されるアクセスデータ２１０（たとえばオブジェクトのレプリカがアクセスされたストレージ位置、オブジェクトのレプリカがストレージ位置にてアクセスされた時間、ストレージ位置でのオブジェクトのアクセスの頻度などに関するデータ）および／またはグローバル状態２１１とともに配置ポリシー２１２を使用して、位置割当デーモン（ＬＡＤ： location assignment daemon）２０６は、オブジェクトまたはジャーナルの新しいコピーをどこに作成するべきかと、どのコピーが削除され得るかとを決定する。新しいコピーが作成されるべきである場合、レプリケーション要求はレプリケーションキュー２２２に挿入される。いくつかの実現例において、ＬＡＤ２０６は、分散ストレージシステム２００についてグローバルにオブジェクトまたはジャーナルのレプリカを管理する。言いかえれば、分散ストレージシステム２００において１つのＬＡＤ２０６のみが存在する。配置ポリシー２１２の使用およびＬＡＤ２０６のオペレーションは以下により詳細に記載される。

【0022】

なお、一般に、それぞれの配置ポリシー２１２は、保存するべきオブジェクトのレプリカの数、どのタイプのデータストアにレプリカが保存されるべきであるか、コピーが保存されるべきストレージ位置などを特定し得る。いくつかの実現例では、オブジェクトについてのそれぞれの配置ポリシー２１２は、分散ストレージシステムに存在しなければならないオブジェクトの最小数のレプリカと、分散ストレージシステムに存在することが許されるオブジェクトの最大数のレプリカと、オブジェクトのレプリカが格納されるべきであるストレージデバイスタイプと、オブジェクトのレプリカが格納され得る位置と、オブジェクトのレプリカが格納され得ない位置と、オブジェクトについての配置ポリシーが適用されるオブジェクトについてのある範囲の期間とからなる群から選択される基準を含む。たとえば、第１の配置ポリシーは、ウェブメールアプリケーションにおける各オブジェクトが、最低２つのレプリカおよび最大５つのレプリカを有さなければならないということを特定し得、当該オブジェクトのレプリカは中国の外のデータセンタに格納され得、各オブジェクトの少なくとも１つのレプリカがテープ上に格納されなければならない。ウェブメールアプリケーションについての第２の配置ポリシーはさらに、３０日より古いオブジェクトについて、最低１つのレプリカおよび最大３つのレプリカが分散ストレージシステム２００に格納されるということを特定し得、オブジェクトのレプリカは中国の外のデータセンタに格納され得、各オブジェクトの少なくとも１つのレプリカがテープ上に格納されなければならない。

【0023】

いくつかの実現例において、ユーザ２４０は、ウェブブラウザ２４４を実行可能であるコンピュータシステムまたは他のデバイスであり得るユーザシステム２４２とインタラクションする。ユーザアプリケーション２４６は、ウェブブラウザにおいて実行されており、ネットワークを使用して分散ストレージシステム２００に格納されたデータへのアクセスするよう、データベースクライアント２４８によって提供される機能を使用する。ネットワークは、インターネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、無線ネットワーク（ＷｉＦｉ）、ローカルイントラネット、または、これらの任意の組合せであり得る。いくつかの実現例では、データベースクライアント２４８は、要求に応答するために適切なインスタンスを識別するよう、グローバル構成ストア２０４における情報を使用する。いくつかの実現例において、ユーザアプリケーション２４６は、ウェブブラウザ２４４なしでユーザシステム２４２上で実行される。例示的なユーザアプリケーションは、電子メールアプリケーションおよびオンラインビデオアプリケーションを含む。

【0024】

いくつかの実現例において、各インスタンスは、分散ストレージシステムに格納されるオブジェクトの各々についてオブジェクトメタデータ２２８を格納する。いくつかのインスタンスは、インスタンス（「ローカルインスタンス」と称される）に格納されるレプリカを有するオブジェクトについてのみオブジェクトメタデータ２２８を格納する。いくつかのインスタンスは、分散ストレージシステムにおいて任意の場所に格納されたすべてのオブジェクトのついてのオブジェクトメタデータ２２８を格納する（「グローバルインスタンス」と称される）。オブジェクトメタデータ２２８は、図３、図４および図５に関してより詳細に記載される。

【0025】

いくつかの実現例では、各インスタンスは、分散ストレージシステム２００に格納されるジャーナルの各々について、ジャーナルメタデータ２３６を格納する。いくつかのインスタンスは、インスタンスに格納されるレプリカを有するジャーナルについてのみ、ジャーナルメタデータ２３６を格納する。いくつかのインスタンスは、分散ストレージシステムにおけるいずれかの場所に格納されるすべてのジャーナルについてジャーナルメタデータを格納する。ジャーナルメタデータは、図３、図４、図５および図８に関して以下により詳細に記載される。

【0026】

複数のタイプのジャーナルがデータストア２２４に格納される。ジャーナルの大多数は、クローズド（closed）ジャーナル２３０である。クローズドジャーナル２３０は、いずれの付加的なオブジェクトチャンクも格納しないが、コンテンツを削除およびコンパクト化（compacted）し得る。いくつかの実現例では、同じ配置ポリシー２１２についての２つ以上の小さなクローズドジャーナル２３０は、単一の置換クローズドジャーナル２３０を形成するためにともに結合（stitched）され得る。クローズドジャーナル２３０内のデータは削除およびコンパクト化され得るので、クローズドジャーナル２３０は、時間とともに小さくなり、これにより、結合の候補になり得る。

【0027】

クローズドジャーナル２３０に加えて、インスタンス１０２はオープンジャーナル２３２および２３４を有し得る。図２に示されるように、オープンジャーナルは、プライマリジャーナル２３２またはセカンダリジャーナル２３４のいずれかとして指定される。プライマリジャーナル２３２およびセカンダリジャーナル２３４はペアとなり、異なるインスタンスに位置する。以下により詳細に記載されるように、プライマリジャーナル２３２は、格納のためのチャンク２３８を受け取り、対応するセカンダリジャーナル２３４が格納されているインスタンスにチャンク２３８のコピーを送信する。

【0028】

図３は、いくつかの実現例に従ったサーバ３００のブロック図である。サーバ３００は典型的に、１つ以上の処理ユニット（ＣＰＵ）３０２と、現在の日付および／または時間を報告するクロック３０３と、１つ以上のネットワークまたは他の通信インターフェイス３０４と、メモリ３１４と、これらのコンポーネントを相互接続するための１つ以上の通信バス３１２とを含む。通信バス３１２は、システムコンポーネントを相互接続しシステムコンポーネント同士間の通信を制御する回路（チップセットとも時に称される）を含み得る。いくつかの実現例では、クロック３０３は、クロックサーバ（たとえばクォーラムクロックサーバまたはネットワーク上の任意の他のクロックサーバなど）と周期的に同期するローカルクロックである。サーバ３００は、表示デバイス３０８および入力デバイス３１０（たとえばキーボード、マウス、タッチスクリーン、キーパッドなど）を含むユーザインターフェイス３０６を随意に含み得る。メモリ３１４は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭまたは他のランダムアクセスソリッドステートメモリデバイスのような高速ランダムアクセスメモリを含み、また、１つ以上の磁気ディスクストレージデバイス、光学ディスクストレージデバイス、フラッシュメモリデバイス、または、他の不揮発性ソリッドステートストレージデバイスといった不揮発性メモリを含んでもよい。メモリ３１４は、ＣＰＵ３０２からリモートに位置する１つ以上のストレージデバイスを随意に含み得る。メモリ３１４、または、代替的にはメモリ３１４内の不揮発性メモリデバイスは、コンピュータ読取可能ストレージ媒体を含む。いくつかの実現例において、メモリ３１４は、以下のプログラム、モジュールおよびデータ構造またはそのサブセットを格納する。すなわち、
・さまざまな基本的なシステムサービスを処理するとともにハードウェア依存タスクを実行するためのプロシージャを含むオペレーティングシステム３１６、
・インターネット、他のワイドエリアネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなどのような、１つ以上の通信インターフェイス３０４（有線または無線）および１つ以上の通信ネットワークを介して他のコンピュータにサーバ３００を接続するために使用される通信モジュール３１８、
・入力デバイス３１０を介してユーザからコマンドを受け取り、かつ、表示デバイス３０８においてユーザインターフェイスオブジェクトを生成する随意のユーザインターフェイスモジュール３２０、
・本願明細書に記載されるような構成２０４、
・本願明細書に記載されるようなＬＡＤ２０６、
・本願明細書に記載されるようなアクセスデータ２１０、
・本願明細書に記載されるようなグローバル状態２１１、
・本願明細書に記載されるような配置ポリシー２１２、
・分散ストレージシステムに格納されるオブジェクトについてのオブジェクトメタデータ２２８（オブジェクトメタデータ２２８は、分散ストレージシステム内のオブジェクトを一意に識別するオブジェクトＩＤ３３０を含み得る。メタデータ２２８は、人またはエンティティの名称および／または識別子（たとえば電子メールアドレス）であり得るオブジェクトのオーサ（author）３３２を含み得る。いくつかの実現例では識別子は一意である。メタデータは、オブジェクトが作成された（たとえば、分散ストレージシステムにアップロードされた）日付スタンプまたはタイムスタンプ３３４を含み得る。メタデータは、バイトまたはアロケーションブロックで典型的に測定されるオブジェクトのサイズ３３６を含み得る。メタデータは、個々に割り当てられ得るか、または、他の基準に基づき割り当てられ得る割当配置ポリシー３３８を含む（たとえば米国からアップロードされるすべてビデオは、同じ割当配置ポリシー３３８を有し得る）。配置ポリシーの使用は、図５〜図６および図９Ａ〜図９Ｃに関して以下により詳細に記載される。メタデータ２２８は、各オブジェクトについてのコンテンツチャンクを識別するチャンクＩＤ３４６のセットを含む。いくつかの実現例において、チャンクＩＤはオブジェクト内のオフセットとして特定される。たとえば、第１のチャンクは０のオフセットを有する。いくつかの実現例において、オフセットはメガバイトで特定される。いくつかの実現例において、チャンクＩＤは（ＧＵＩＤのような）一意識別子である。いくつかの実現例において、各チャンクＩＤは、チャンクのオフセットにオブジェクトＩＤを連結することにより形成される。いくつかの実現例では、チャンクＩＤは、コンテンツハッシュまたはコンテンツダイジェストを使用して形成される。各チャンクＩＤに対応するのは、割当ジャーナルＩＤ３４８であり、割当ジャーナルＩＤ３４８は、対応するチャンクがどのジャーナルに格納されるか示す。）、ならびに、
・分散ストレージシステム２００に格納される各ジャーナルについてのジャーナルメタデータ２３６（ジャーナルメタデータ２３６は、各ジャーナルについてのジャーナルＩＤ３７０と、ジャーナルが格納されるジャーナル位置３７２のセットとを含む。ジャーナル位置３７２は、ジャーナルが格納される各インスタンス１０２を特定し、ジャーナルを格納するインスタンス１０２にあるデータストア２２４を特定し得る。ジャーナルメタデータ２３６はさらに、各ジャーナルに関連付けられる配置ポリシーＩＤ３７４を含む。配置ポリシーＩＤ３７４は、ジャーナルに関連付けられる一意の配置ポリシー２１２を識別する。）
を格納する。

【0029】

上記の識別された要素の各々は、以前に言及されたメモリデバイスのうちの１つ以上に格納され得、上に記載された機能を実行するための命令のセットに対応する。命令のセットは、１つ以上のプロセッサ（たとえばＣＰＵ３０２）によって実行され得る。上記の識別されたモジュールまたはプログラム（すなわち命令のセット）は、別個のソフトウェアプログラム、プロシージャまたはモジュールとして実現される必要はなく、したがって、これらのモジュールのさまざまなサブセットは、さまざまな実現例において組み合わせられ得るか、または、そうでなければ再構成され得る。いくつかの実現例において、メモリ３１４は、上で識別されたモジュールおよびデータ構造のサブセットを格納し得る。さらに、メモリ３１４は、上で記載されていない付加的なモジュールおよびデータ構造を格納し得る。

【0030】

図３は「サーバ」を示すが、図３は、本願明細書において記載される実現例の構造図としてよりも、サーバ３００のセットに存在し得るさまざまな特徴の機能説明としてより多く意図される。実際には、および、当業者によって認識されるように、別々に示された項目は、組み合わされ得、いくつかの項目は分離され得る。たとえば、図３に別々に示されるいくつかの項目は単一のサーバ上で実現され得、また、単一の項目は、１つ以上のサーバによって実現され得る。サーバの実際の数、および、特徴がどのようにそれらの間で割り当てられるかは、実現例ごとに変動することになり、ピーク使用期間の間および平均使用期間の間にシステムが処理しなければならないデータトラフィックの量に部分的に依存し得る。いくつかの実現例では、ＬＡＤ２０６のサブセット、アクセスデータ２１０、グローバル状態２１１および配置ポリシー２１２は、別個のサーバ上に位置する。たとえば、ＬＡＤ２０６はサーバ（またはサーバのセット）に位置し得、アクセスデータ２１０およびグローバル状態２１１は、統計サーバ２０８（または統計サーバ２０８のセット）に位置され得るとともに統計サーバ２０８（または統計サーバ２０８のセット）によって維持され得、配置ポリシー２１２は別のサーバ（または別のサーバのセット）に位置し得る。

【0031】

図４は、いくつかの実現例に従った、インスタンス１０２についてのインスタンスサーバ４００のブロック図である。インスタンスサーバ４００は典型的に、モジュールを実行するための１つ以上の処理ユニット（ＣＰＵ）４０２と、現在の日付および／または時間を報告するクロック４０３と、メモリ４１４に格納され、これにより処理オペレーションを実行するプログラムおよび／または命令と、１つ以上のネットワークまたは他の通信インターフェイス４０４と、メモリ４１４と、これらのコンポーネントを相互接続するための１つ以上の通信バス４１２とを含む。いくつかの実現例において、クロック４０３は、周期的にクロックサーバと同期するローカルクロックである（たとえばクォーラムクロックサーバまたはネットワーク上の任意の他のクロックサーバなど）。いくつかの実現例において、インスタンスサーバ４００は、表示デバイス４０８および１つ以上の入力デバイス４１０を含むユーザインターフェイス４０６を含む。いくつかの実現例では、メモリ４１４は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭまたは他のランダムアクセスソリッドステートメモリデバイスのような高速ランダムアクセスメモリを含む。いくつかの実現例では、メモリ４１４は、１つ以上の磁気ディスクストレージデバイス、光学ディスクストレージデバイス、フラッシュメモリデバイス、または、他の不揮発性ソリッドステートストレージデバイスといった不揮発性メモリを含み、いくつかの実現例において、メモリ４１４は、ＣＰＵ４０２からリモートに位置する１つ以上のストレージデバイスを含む。メモリ４１４、または、代替的にはメモリ４１４内の不揮発性メモリデバイスは、コンピュータ読取可能ストレージ媒体を含む。いくつかの実現例では、メモリ４１４またはメモリ４１４のコンピュータ読取可能ストレージ媒体は、以下のプログラム、モジュールおよびデータ構造、または、そのサブセットを格納する。すなわち、
・さまざまな基本的なシステムサービスを処理するとともにハードウェア依存タスクを実行するためのプロシージャを含むオペレーティングシステム４１６、
・インターネット、他のワイドエリアネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなどといった、１つ以上の通信ネットワークインターフェイス４０４（有線または無線）および１つ以上の通信ネットワークを介して他のインスタンスサーバまたはコンピュータにインスタンスサーバ４００を接続するために使用される通信モジュール４１８、
・入力デバイス４１０を介してユーザからコマンドを受け取り、かつ、表示デバイス４０８においてユーザインターフェイスオブジェクトを生成する随意のユーザインターフェイスモジュール４２０、
・本願明細書に記載されるようなレプリケーションモジュール２２０およびレプリケーションキュー２２２、
・図３に関して記載されような、ジャーナル２３０、２３２および２３４にオブジェクトチャンク２３８を格納するデータストア２２４（たとえば分散データベース、ファイルシステム、テープストレージ、ビッグテーブル（Big Tables）など）、
・サーバ３００に関して図３に記載されたような、オブジェクトメタデータ２２８および対応するメタデータ要素３３０〜３３８、３４６および３４８、ならびに、
・サーバ３００に関して図３に記載されるような、ジャーナルメタデータ２３６ならびに対応するジャーナルメタデータ要素３７０、３７２および３７４
を格納する。

【0032】

上記の識別された要素の各々は、以前に言及されたメモリデバイスのうちの１つ以上に格納され得、上に記載された機能を実行するための命令のセットに対応する。命令のセットは、１つ以上のプロセッサ（たとえばＣＰＵ４０２）によって実行され得る。上記の識別されたモジュールまたはプログラム（すなわち命令のセット）は、別個のソフトウェアプログラム、プロシージャまたはモジュールとして実現される必要はなく、したがって、これらのモジュールのさまざまなサブセットは、さまざまな実現例において組み合わせられ得るか、または、そうでなければ再構成され得る。いくつかの実現例において、メモリ４１４は、上で識別されたモジュールおよびデータ構造のサブセットを格納し得る。さらに、メモリ４１４は、上で記載されていない付加的なモジュールおよびデータ構造を格納し得る。

【0033】

図４は「インスタンスサーバ」を示すが、図４は、本願明細書において記載される実現例の構造図としてよりも、インスタンスサーバ４００のセットに存在し得るさまざまな特徴の機能説明としてより多く意図される。実際には、および、当業者によって認識されるように、別々に示された項目は組み合わされ得、いくつかの項目は分離され得る。たとえば、図４に別々に示されるいくつかの項目は単一のサーバ上で実現され得、また、単一の項目は、１つ以上のサーバによって実現され得る。サーバの実際の数、および、特徴がどのようにそれらの間で割り当てられるかは、実現例ごとに変動することになり、ピーク使用期間の間および平均使用期間の間にサーバが処理しなければならないデータトラフィックの量に部分的に依存し得る。たとえば、単一のインスタンス１０２では、１００個のインスタンスサーバ４００または何千個ものインスタンスサーバ４００が存在してもよい。

【0034】

いくつかの実現例において、クライアントに対してより速い応答を提供し、かつ、フォルトトレランスを提供するために、インスタンスにおいて実行される各プログラムまたはプロセスは、複数のコンピュータの間で分散される。プログラムまたはプロセスの各々に割り当てられるインスタンスサーバ４００の数は変動し得るとともに、ワークロードに依存し得る。

【0035】

図５は、いくつかの実現例に従ったオブジェクトチャンクの格納のためのジャーナルの使用を示す。図５は、データストア２２４と、オブジェクトメタデータ２２８の部分と、ジャーナルメタデータ２３６の部分とを示しており、これらはすべて例示的なインスタンス１０２に存在する。このデータストア２２４には多くのジャーナル２３０、２３２および２３４が格納されているので、２次元グリッドにおいてそれらを視覚的に構成することは有用である。（もちろん、視覚表示は、データストアにおけるジャーナルの実際の物理的なストレージとは無関係である。）図において、ジャーナルはジャーナルの「ロウ（row）」にパーティショニングされ、各ロウは単一の配置ポリシー２１２に対応する。たとえば、第１のロウ５０２−Ｐ１は、配置ポリシーＰ１（２１２）に対応し、クローズドジャーナル２３０、オープンプライマリジャーナル２３２、および、オープンセカンダリジャーナル２３４を含む。第１のロウ５０２−Ｐ１におけるこれらのジャーナルのすべては、配置ポリシーＰ１に関連付けられる。第２のロウ５０２−Ｐ２は、配置ポリシーＰ２（２１２）に対応し、最後のロウ５０２−ＰＮは配置ポリシーＰＮ（２１２）に対応する。典型的に、配置ポリシーの数は１０個、２０個、５０個または恐らく１００個といったように少ない。配置ポリシーの数が増加すると、オブジェクトレプリカの管理はあまり効率的でなくなる。

【0036】

さらに、データストア２２４におけるジャーナルは、図５において２つのカラムへ視覚的にパーティショニングされる。第１のカラムは、ジャーナルの大多数であるクローズドジャーナル２３０を識別する。第２のカラムは、オープンプライマリジャーナル２３２およびオープンセカンダリジャーナル２３４を含む。各ジャーナルにおいてさまざまな長方形２３８によって示されるように、各ジャーナル（クローズドジャーナル２３０、オープンプライマリジャーナル２３２またはオープンセカンダリジャーナル２３４）はオブジェクトチャンク２３８を含む。オブジェクトチャンクはさまざまなサイズであり得るが、実現例は典型的に固定最大サイズをセットする（たとえば２メガバイト、４メガバイトまたは８メガバイト）。ジャーナル内におけるオブジェクトチャンク２３８の図は、ジャーナルがさまざまなサイズの多くのオブジェクトチャンクを格納するが、そうでなければオブジェクトチャンクの実際の物理的な格納を示しているわけではないという事実を正確に伝える（たとえば、割り当てられていないスペースの初めに各新しいオブジェクトチャンク２３８が追加されるので、オブジェクトチャンク同士間には未使用のスペースは一般に存在しない）。

【0037】

図５は、オープンジャーナル２３２および２３４のさまざまな組合せが各配置ポリシーについて可能であることを示す。本願明細書において図および説明において異なるジャーナルレプリカを識別するために、「２３２．Ｐ４．７」といった三部分ラベルが使用される場合がある。第１の部分（たとえば「２３２」）は、ジャーナルのタイプを識別し（２３０＝クローズド，２３２＝オープンプライマリ，２３４＝オープンセカンダリ）、第２の部分（たとえば「Ｐ４」）は、当該ジャーナルについての配置ポリシーを特定し、第３の部分（たとえば「７」）は、当該ジャーナルについてのシーケンシャル番号を単に特定する（たとえば「２３２．Ｐ４．７」における「７」は、配置ポリシーＰ４についての第７番目のオープンジャーナルを特定する）。

【0038】

図５に示されるように、配置ポリシーＰ１について、単一のオープンプライマリジャーナル２３２．Ｐ１．１が存在し、オープンセカンダリジャーナルは存在しない。配置ポリシーＰ２について、２つのオープンプライマリジャーナル２３２．Ｐ２．１および２３２．Ｐ２．２が存在する。配置ポリシーＰＮについて、１つのオープンプライマリジャーナル２３２．ＰＮ．１および１つのオープンセカンダリジャーナル２３４．ＰＮ．１が存在する。これらの例が示すように、オープンプライマリジャーナル２３２およびオープンセカンダリジャーナル２３４の数は、配置ポリシー同士間で変動し得、典型的に、各配置ポリシー２１２についての新しいオブジェクト２２６の予想される数と、それらのオブジェクト２２６についての所望の位置とに基づき、各ポリシー２１２について構成される。

【0039】

各インスタンス１０２はさらに、以前に図３に関して記載されたように、オブジェクトメタデータ２２８およびジャーナルメタデータ２３６の両方を格納する。各オブジェクト２２６について、オブジェクトメタデータ２２８は、（一意にオブジェクトを識別する）オブジェクトＩＤ３３０と、オブジェクトからオブジェクトチャンク２３８を識別する１つ以上のチャンクＩＤ３４６のセットと、各チャンクＩＤ２３６に関連付けられる割り当てられたジャーナルＩＤ３４８とを含む。オブジェクトが複数のチャンク２３８を有する場合、チャンク２３８は、（たとえばロードバランシングのために）同じジャーナルにすべて格納される必要は必ずしもないので、オブジェクトメタデータ２２８は、各チャンクＩＤ３４６に割り当てられるジャーナルＩＤ３４８をトラッキングしなければならない。

【0040】

各インスタンス１０２はさらに、インスタンス１０２に格納される各ジャーナルについてジャーナルメタデータ２３６を格納する。メタデータ２３６は、各ジャーナルについてのジャーナルＩＤ３７０と、位置３７２のセットとを含む。いくつかの実現例において、位置ＩＤは、ジャーナルが格納されるインスタンスを識別する。いくつかの実現例において、位置ＩＤはさらに、特定されたインスタンスにあるデータストアを識別する。いくつかの実現例において、インスタンス識別子およびデータストア識別子は、各ジャーナルについて別個の属性として格納される。いくつかの実現例において、ジャーナルは、単一のインスタンスにある２つ以上のデータストアに格納され得る（たとえばファイルシステムデータストアおよびテープバックアップデータストア）。ジャーナルメタデータ２３６はさらに、各ジャーナルに対応する一意の配置ポリシー２１２を特定する配置ポリシーＩＤ３７４を含む。各ジャーナルは、配置ポリシー３３８がジャーナルの配置ポリシーとマッチするオブジェクトチャンク２３８のみを格納する。

【0041】

図６は、いくつかの実現例が新しいオブジェクト２２６の格納をどのように管理するかを示す。図６に示されるように、各新しいオブジェクトはオブジェクトコンテンツ（すなわちオブジェクト２２６自体）と、オブジェクトＩＤ３３０（たとえば５８４４０９１２）と、割当配置ポリシー３３０（たとえばＰ３）とを有する。新しいオブジェクト２２６は、オンライン電子メールアプリケーションおよびビデオシェアリングウェブサイトなどといった多くの異なるアプリケーション２４６から得られ得る。分散ストレージシステム２００は、新しいオブジェクト２２６を受け取り、インスタンス１０２−１のような適切なインスタンスに新しいオブジェクト２２６を方向付け（６０２）する。いくつかの実現例において、アプリケーション２４６は新しいオブジェクト２２６を特定のインスタンス１０２−１に方向付けする。アプリケーション２４６によって選択されるインスタンス１０２−１が適切でない場合、いくつかの実現例は、オブジェクト２２６を適切なインスタンスに転送する（たとえば、配置ポリシー２１２がヨーロッパにおける格納を特定せず、オブジェクト２２６がヨーロッパにおけるインスタンスにおいて受け取られる場合、当該インスタンスは、オブジェクト２２６を別のインスタンスに転送し得る）。

【0042】

たいていのオブジェクトは、中程度のサイズ（たとえば３００キロバイト未満）を有するが、大きいオブジェクトがいくつか存在する。いくつかの実現例は、大きいオブジェクトを複数のチャンク２３８へ分割する（６０４）。一般に、各実現例は、典型的に単位がメガバイトで特定される（たとえば２、４、８、１６、または３２メガバイト）チャンクサイズをセットするか、または、当該チャンクサイズをセットするために構成可能であるパラメータを有する。チャンクサイズより大きい各オブジェクトは複数のチャンクへ分割され、チャンクサイズ以下のサイズを有する各オブジェクトは単一のチャンクからなる。図６における例示において、３つのチャンクＣ１、Ｃ２およびＣ３が存在する。この例示において、チャンクの各々は７文字の英数字チャンクＩＤ３４６を有しているが、一意に各オブジェクト内のチャンクを識別する多くの代替的なチャンクＩＤフォーマットが可能である。いくつかの実現例において、チャンクＩＤ３４６は、コンテンツハッシュまたはコンテンツダイジェストを使用して生成される。

【0043】

いくつかの実現例において、多くのオブジェクト重複物が存在する場合がある（たとえば、メール添付物がある人々のグループに送られ、その後、多くのさらなる人々に転送される）ので、重複除外（de-duplication）は効率的な格納に有用であり得る。したがって、いくつかの実施形態において、オープンプライマリジャーナルに「新しい」チャンク２３８のみを格納する（６０６）よう、各新しいチャンク２３８のコンテンツが、（たとえばコンテンツハッシュまたはコンテンツダイジェストを使用して）既存のオブジェクトチャンク２３８と比較される（６０６）。図５に示されるように、チャンクＣ２は新しく、配置ポリシーＰ３に対応しているので、チャンクＣ２は、配置ポリシーＰ３に対応するオープンプライマリジャーナル２３２．Ｐ３．１に格納される。もちろん、重複除外は配置ポリシーの文脈内にのみ存在する。２つのチャンクが同一であるが、異なる配置ポリシーに割り当てられている場合、２つのチャンクは異なるジャーナルに保存されることになる。言い換えれば、新しいチャンクが受け取られる場合、新しいチャンクは、同じ配置ポリシーについてのチャンクとのみ比較される。同じ配置ポリシーについて保存された同一のチャンクが既に存在する場合にのみ、チャンクは「重複物」である。

【0044】

オブジェクトチャンクＣ２が新しいかどうかにかかわらず、インスタンス１０２−１は、チャンク２３８についてオブジェクトメタデータ２２８を格納する（６０８）。図３〜図５に関して上述したように、メタデータ２２８は、オブジェクトＩＤ３３０と、チャンクＩＤ３４６と、各チャンクが格納されるジャーナルについてのジャーナルＩＤ３４８とを含む。いくつかの実現例において、オブジェクトチャンク２３８についてのチャンクＩＤ３４６は単に、オブジェクト内のチャンク２３８の開始に対するオフセットである。図６に示されるオブジェクトメタデータ２２８はさらに、単一のオブジェクトについてのチャンクが同じジャーナルに格納される必要はないということを示す。チャンクＣ１およびＣ３（チャンクＩＤ Ｃ１９００５６およびＣ０９８６６３）は、ジャーナルＩＤ Ｊ７７２９８０４５を有するジャーナル２３２．Ｐ３．２に存在し、チャンクＣ２（チャンクＩＤ Ｃ２５０１１６）は、ジャーナルＩＤ Ｊ８２１１７０９４を有するジャーナル２３２．Ｐ３．１に存在する。

【0045】

チャンクＣ２はセカンダリジャーナル２３４．Ｐ３．１における格納のために、インスタンス１０２−２に送信され（６１０）、チャンクＣ１およびＣ３は、セカンダリジャーナル２３４．Ｐ３．２における格納のためにインスタンス１０２−２に送信される（６１２）。

【0046】

図６はさらに、プライマリジャーナル２３２が、その対応するセカンダリジャーナルと物理的に同一である必要はないことを示す。まず、チャンクＣ１およびＣ３がプライマリジャーナル２３２．Ｐ３．２においてその順に格納され、これらのチャンクはセカンダリジャーナル２３４．Ｐ３．２においてその逆の順に格納されるということが分かる。ジャーナルがオープンである間、個々のチャンク２３８は、独立してレプリケートされるか、異なるネットワークパスを横断するか、または、異なるプロセッサ４０２によって処理され得るので、それらが同じ順でセカンダリジャーナル２３４．Ｐ３．２にロードされる保証はない。異なる順が存在し得るという事実は、図７に関して以下に記載されるように、各ジャーナル内のチャンクインデックスによって扱われる。さらに、プライマリジャーナル２３２．Ｐ３．１は、当該図において「Ｇ」とラベル付されたガーベッジ「チャンク」６２０の存在を示す。アップロードの間に時として、スペースを消費する障害またはグリッチが存在する場合がある。たとえばアップロードの間に、オブジェクトのためのスペースが割り当てられるが、チャンクが実際に追加されない場合がある。ソフトウェアはアップロードを再び試み、これにより、チャンクのための新しいスペースが割り当てられる。これは、ジャーナル２３２内にホール（hole）またはガーベッジ（garbage）を残し得る。この場合、ガーベッジ６２０はセカンダリジャーナルに送信されないので、プライマリジャーナルはセカンダリジャーナルと物理的に異なる。

【0047】

図７は、いくつかの実現例に従ったオープンジャーナルの構造を示す。図７はオープンプライマリジャーナル２３２を記載するが、オープンセカンダリジャーナル２３４の構造は同じまたは同様である。ジャーナル２３２は、ヘッダー７０２およびストレージスペース７１４のブロックを有する。ストレージスペース７１４は、既にオブジェクトチャンク２３８を格納している充填部分７１０と、現在未使用である非充填部分７１２とを含む。これらの記述子は、いくつかの理由により完全には正確ではない。第１に、「充填」スペース７１０は、有用なコンテンツを有さないガーベッジ部分６２０を含み得る。第２に、未使用スペースは必ずしもすべて同時に割り当てられるわけではない。いくつかの実現例は、ジャーナルについて全スペースを一度に割り当て、充填されると、（端部に少ない量の未使用スペースを潜在的に残して）当該ジャーナルをクローズする。しかしながら、他の実現例では、付加的なスペースのブロックは、ジャーナルがあるサイズの限界に達するか、または、ある量の時間（たとえば１日）が経過するまで、必要に応じて割り当てられる。

【0048】

ジャーナルについてのヘッダー７０２は、ジャーナル２３２に関する重要な内部情報を含む。ヘッダー７０２は、未使用スペース７１２がジャーナルにおいてどこで開始するかを特定するフィールド７０４を含む。新しいチャンク２３８が充填スペース７１０の端部に追加されるごとに、オフセット７０４は、ジャーナル２３２が次のチャンクを格納するよう準備されるように、チャンク２３８のサイズだけインクリメントされる。

【0049】

ヘッダー７０２はさらにチャンクインデックス７０６を含む。ジャーナル２３２についてのチャンクインデックス７０６は、各チャンク２３８がジャーナル２３２内のどこに位置するのかと、そのサイズとを特定し、これにより、（不揮発性ストレージまたはキャッシュからにかかわらず）チャンクデータの高速読出を可能にする。チャンクインデックス７０６についてのキーは、一意にチャンクを識別するチャンクＩＤ３４６である。なお、複数の異なるオブジェクトＩＤ３３０は、同じ物理的なチャンクを指し得る。多くのエントリが同じオブジェクトチャンク２３８を指す大きなチャンクインデックス７０４を回避するために、実現例は典型的に、同じ物理的なコンテンツを参照するために単一のチャンクＩＤを利用する。たとえば、チャンクＩＤ３４６は、コンテンツハッシュまたはコンテンツダイジェスト（またはこれらの組合せ）であり得る。各チャンクＩＤ３４６について、チャンクインデックス７２０は、ストレージスペース７１４内のチャンク２３８についてのオフセット７２０およびサイズ７２２を特定する。オフセット７２０は、ジャーナル２３２の始めからのオフセット、または、充填スペース７１０の始めからのオフセットとして特定され得る。いくつかの実現例では、チャンクインデックスは、チャンクが削除されて充填スペース７１０がコンパクト化される際に後で使用される削除マーカといった付加的な情報を有する。

【0050】

ヘッダー７０２は同様に、実現例の詳細に対応するよう、他のジャーナルデータ７０８を含み得る。たとえば、他のジャーナルデータ７０８は、ジャーナルの始めからストレージスペース７１４の始めまでのオフセットを特定し得る（すなわちヘッダーのサイズ）。いくつかの実現例では、他のジャーナルデータは、短いライフスパンを有するように指定されるジャーナルについての「生存時間（time to live）」パラメータを含む。

【0051】

図７におけるジャーナルの構造はオープンプライマリジャーナル２３２のためのものであるが、同じ基本構造は、オープンセカンダリジャーナル２３４およびクローズドジャーナル２３０に同様に適用される。

【0052】

図８は、いくつかの実現例に従って、ジャーナルが１つのインスタンスから別のインスタンスにレプリケートされる場合、オブジェクトメタデータ２２８およびジャーナルメタデータ２３６に何が起こるかを示す。この例示において、ジャーナルＩＤ Ｊ８２１１７０９４を有するクローズドジャーナル２３０は、（インスタンスＩＤ＝７２３を有する）インスタンス１０２−１から（インスタンスＩＤ４２８を有する）インスタンス１０２−４にレプリケート（８２０）される。ジャーナル２３０自体が単位としてレプリケートされるので、全コンテンツが正確にレプリケートされる。たとえば、（チャンクＩＤ Ｃ４０８３３５を有する）チャンクＣ８は、ジャーナル内のまったく同じ位置にある。もちろん、レプリケーションの後、インスタンス１０２−１および１０２−４は独立して削除およびコンパクションを扱うので、それらの物理構造は、レプリケーションの後、同じままであることは保証されない。

【0053】

図８はさらに、レプリケーション８２０の前および後のオブジェクトメタデータ２２８およびジャーナルメタデータ２３６の部分を示す。示されるように、オブジェクトメタデータ２２８におけるレコード８０２〜８１４はレプリケーション８２０によって変更されていない。各オブジェクト２２６は同じチャンク２３８を有し、チャンク２３８は同じジャーナル２３０に格納される。たとえば、（ロウ８０４における）チャンクＩＤ Ｃ４０８３３５を有するチャンクは変更されない。他方、ジャーナルＩＤ Ｊ８２１１７０９４（３７０−１）を有するジャーナル２３０についてのジャーナルメタデータ２３６は変更される。ジャーナル位置３７２のセットは、３７２−１（Ａ）から、（インスタンス１０２−４についての）新しい位置４２８を含む３７２−１（Ｂ）に変更する。

【0054】

図９Ａ〜図９Ｃは、いくつかの実現例に従った分散ストレージシステム２００においてオブジェクトレプリカの配置を管理する（９０２）方法９００を示す。当該方法は、１つ以上のプロセッサおよびメモリを有する分散ストレージシステムの第１のインスタンス１０２において実行（９０４）される。メモリは、複数のオブジェクトを格納する（９０６）。メモリはさらに、１つ以上のプロセッサによる実行のための１つ以上のプログラムを格納する（９０８）。いくつかの実現例において、方法９００のすべてまたは一部は、位置割当デーモン２０６によって実行される。いくつかの実現例において、分散ストレージシステムは複数のインスタンスを有する（９１０）。これらの実現例のうちのいくつかにおいて、インスタンスの少なくともサブセットは、異なる地理的位置にて存在する（９１０）。いくつかの実現例において、各インスタンスはデータセンタに対応する。いくつかの実現例において、各データセンタは１つ以上のインスタンスを含む。

【0055】

第１のインスタンスでは、１つ以上のジャーナル２３２が、オブジェクトチャンクの格納のためにオープンにされる（９１２）。各ジャーナルは、単一のそれぞれの配置ポリシー２１２に関連付けられる（９１４）。いくつかの実現例では、各配置ポリシーは、対象数のオブジェクトレプリカと、オブジェクトレプリカについての位置の対象セットとを特定する（９２６）。いくつかの実現例では、配置ポリシー２１２は、データストア２２４のどのタイプがインスタンスのうちのいくつかにおいて使用されるべきであるか（たとえばディスクまたはテープ）を特定し得る。いくつかの実現例では、分散ストレージシステム２００は、どのジャーナルに各オブジェクトチャンク２３８が格納されているかを特定するオブジェクトメタデータ２２８を含む（９１８）。これは、図３〜図５に関して以前に記載された。いくつかの実現例では、各それぞれのジャーナルは、それぞれのジャーナルに格納された各オブジェクトの位置を特定するチャンクインデックス７０６を含む（９２０）。これは、図７により詳細に記載された。特に、ジャーナル内の各チャンクの位置は、ジャーナル自身に対して識別され、したがって、チャンクインデックス７０６は、ジャーナルがどこに格納されるかにかかわらず正確である。たとえば、オフセットとしてジャーナル内のチャンクの位置を特定することによって、チャンクはリラティブアドレッシング（relative addressing）によってアクセスされ得る。

【0056】

開示された実現例は典型的に、各ジャーナルが格納される位置３７２を特定するジャーナルメタデータ２３６を含む（９２２）。これは、図３〜図５および図８において以前に記載された。

【0057】

オープンプライマリジャーナル２３２およびオープンセカンダリジャーナル２３４の分散は、利用可能なインスタンス１０２と、配置ポリシー２１２と、配置ポリシー２１２による新しいオブジェクト２２６の予想される分散と、新しいオブジェクトがどこ（たとえばヨーロッパ、北米、アジア）からロードされるかと、利用可能なインスタンス１０２の各々での処理リソースと、さまざまなインスタンス同士間のネットワーク帯域幅とを含む多くのファクタに依存する。たとえば、多くのオブジェクトが、特定のインスタンスにおいて特定の配置ポリシーでアップロードされる場合、そのインスタンスでの同じ配置ポリシーについて、複数のジャーナルがオープンにされる（９２４）。いくつかのシナリオにおいて、ロードバランシングに必要とされる場合、単一のインスタンス１０２において、同じ配置ポリシー２１２について、５個、１０個、またはそれ以上のオープンジャーナルが存在し得る。

【0058】

図５および図６に関して上述したように、いくつかの実現例は、第１のインスタンスにおいてオープンにされたジャーナルに対応するジャーナルをオープンにするよう、メッセージを分散ストレージシステム２００の第３のインスタンスに送信する（９１６）。このシナリオにおいて、第１のインスタンスにおいてオープンにされたジャーナル２３２はプライマリジャーナルと称され、第３のインスタンスでオープンにされたジャーナル２３４はセカンダリジャーナルと称される。（もちろん、第１のインスタンスはセカンダリジャーナルも有し得、第３のインスタンスはプライマリジャーナルを有し得る）。

【0059】

第１のインスタンス１０２では、少なくとも第１のオブジェクトチャンクを含む（９２８）第１のオブジェクト２２６が受け取られる（９２８）。これは、図６に関して上に記載された。第１のオブジェクト２２６は第１の配置ポリシー２１２に関連付けられており、したがって、オブジェクト２２６を含むオブジェクトチャンク２３８のすべては第１の配置ポリシー２１２に関連付けられる。第１のオブジェクトチャンク２３８は、関連付けられる配置ポリシーが第１の配置ポリシー２１２とマッチする第１のジャーナル２３２に格納される（９３０）。第１のジャーナル２３２は、配置ポリシーが第１の配置ポリシーとマッチするオブジェクトについてのオブジェクトチャンクのみを格納する（９３２）。いくつかの実現例では、第１のジャーナル２３２に格納された各オブジェクトチャンク２３８は、第３のジャーナル２３４における格納のために、第３のインスタンスに送信される（９３４）。

【0060】

受け取られたオブジェクトがチャンクサイズより大きい場合、オブジェクトは複数のチャンク２３８へ分割される。この場合、第１のオブジェクト２２６は２つ以上のオブジェクトチャンクを含む（９３６）。典型的に、第２のオブジェクトチャンクは、第１のオブジェクトチャンクと異なる（９３６）。（単一のオブジェクト内に２つの同一のチャンクを有することは稀であるが、たとえば、オブジェクトが空のスペースの非常に大きな部分を有する場合に起こり得る。）いくつかの状況では、第２のオブジェクトチャンクが、関連付けられる配置ポリシーが第１の配置ポリシーとマッチする、第１のジャーナルとは異なる第２のジャーナル２３２に格納される（９３８）。第２のジャーナルは、配置ポリシーが第１の配置ポリシーとマッチするオブジェクトについてのオブジェクトチャンクのみを格納する（９３８）。これにより、多くのチャンクを含むオブジェクトは、多くの異なるジャーナルにわたって分散されるチャンクを有し得る。

【0061】

オブジェクト２２６を受け取り、かつ、第１のジャーナル２３２にチャンク２３８を格納するこのプロセスは、関連付けられる配置ポリシー３３８が第１の配置ポリシー２１２にマッチする複数のオブジェクト２２６について、第１の終了条件が発生するまで繰り返される（９４０）。いくつかの実現例では、第１の終了条件は、第１のジャーナルのサイズが予め規定されたしきい値を越える（９４２）場合に発生する。いくつかの実現例では、第１の終了条件は、第１のジャーナルが予め規定された時間スパンの間オープンであった場合（９４４）に発生する。いくつかの実現例は、さまざまな態様でサイズおよび時間を組み合わせる。たとえば、いくつかの実現例は、時間スパンおよびサイズ限界の両方を特定しており、終了条件は、上記のうちのいずれか一方が最初に発生することである。

【0062】

終了条件が発生した後、第１のジャーナルはクローズされ（９４６）、これにより、如何なる付加的なオブジェクトチャンクも第１のジャーナル２３２に格納されることを防止する。一般に、実現例は、第１のジャーナルをクローズする前に、同じ配置ポリシーについての他のジャーナル２３２がまだオープンである（または新しいジャーナルがオープンである）ことを確認する。新しいオブジェクトがいつでも到着し得るので、格納のためにオープンジャーナルを利用可能にしておくことが重要である。別のインスタンスに対応するセカンダリジャーナル２３４が存在する場合、第１のインスタンスは、第１の終了条件が発生する場合に対応するセカンダリジャーナルをクローズするよう、他のインスタンスにメッセージを送信する（９４８）。

【0063】

第１のジャーナル２３２がクローズされた後、ジャーナルはその配置ポリシーに従う。配置ポリシー２１２を満足させることは、ジャーナルレプリカを移動させること、ジャーナルレプリカの新しいコピーを作成すること、または、ジャーナルのレプリカを削除することを必要とし得る。いくつかの状況では、第１のジャーナル２３２は、配置ポリシー２１２に従って、分散ストレージシステム２００の第２のインスタンス１０２にレプリケートされる（９５０）。（他の状況において、第１のジャーナルのレプリカは削除される。）プライマリオープンジャーナル２３２およびセカンダリオープンジャーナル２３４を有する実現例では、それらがひとたびクローズされると、２つの同等なクローズドジャーナル２３０が存在することになる。したがって、レプリケーション９５０のためのソースとして、レプリカのいずれかが使用され得る。レプリケーション９５０が発生する（すなわちトランザクションの一部として）と、第２のインスタンスにジャーナルのコピーが存在することを示すよう、第１のジャーナルについてのジャーナルメタデータ２３６は更新される（９５２）。これは図８に関して上に記載された。

【0064】

ジャーナル２３０がクローズされた後、オブジェクトチャンク２３８が削除され得る。たとえば、オブジェクトはメール添付物に対応し得る。電子メールの受信者が電子メールを削除すれば、当該添付物についての格納分は削除され得る。ある期間の後、当該削除により各ジャーナル内にホールが存在するので、当該無駄にされているスペースを除去するようジャーナルをコンパクト化することが有用である。これは、揮発性メモリのフラグメンテーション、および、未使用スペースをより大きな連続ブロックへと統合するデフラグメンテーションのプロセスに類似している。

【0065】

格納されたオブジェクトチャンクが多くの（たとえば何百、何千または何百万の）異なるオブジェクトに対応し得るので、ジャーナルにおけるオブジェクトチャンクは、当該オブジェクトチャンクへの参照がもはや存在しない場合にのみ削除され得る。したがって、第１のクローズドジャーナル２３０がひとたび選択される（９５４）と、プロセス９００は、オブジェクトメタデータ２２８において参照が存在しない第１のクローズドジャーナル２３０に格納された１つ以上のオブジェクトチャンクを識別する（９５６）。これらの識別されたチャンク２３８について、対応するレコードを除去するようチャンクインデックス７０６が更新される（９５８）。いくつかの実現例では、識別されたオブジェクトチャンクに以前に割り当てられたスペースは、上書きされる（たとえば各バイトがＡＳＣＩＩ０にセットされる）が、他の実現例では、当該スペースはもはや参照されない。いくつかの実現例では、割り当てを解除されたストレージスペースは、他のジャーナルデータ７０８の一部としてトラッキングされる。たとえば、いくつかの実現例は、割り当てを解除されたストレージスペース（たとえばオフセットおよびサイズ）のリストを維持するか、または、割り当てを解除されたスペースをリンク付けされたリストとしてトラッキングする。

【0066】

いくつかの実現例では、ガーベッジコレクションアルゴリズムは、クローズドジャーナルの各々をコンパクト化する（９６０）よう、周期的に実行される。当該コンパクションプロセスは、格納されたオブジェクトチャンクを連続的なブロックへ統合し（９６０）、これにより、ジャーナル２３０のサイズを低減する。時間にわたって、より多くのオブジェクトチャンクが削除されると、ジャーナル２３０は小さくなり得る。多くの小さなジャーナルを管理することには、個々のオブジェクトを管理することと同様のオーバーヘッドが存在するので、ジャーナルの格納の利益は縮小される。この問題に対応するために、いくつかの実現例は、２つ以上のクローズドジャーナル同士を結合して（９６２）単一の置換ジャーナルを形成し、当該２つ以上のジャーナルに以前に格納されたオブジェクトチャンクは置換ジャーナルに格納されているということを示すようオブジェクトメタデータ２２８を更新する（９６２）。結合オペレーションは、完全に新しいジャーナルを形成することと、関連するオブジェクトのすべてについてメタデータを更新することとを必要とするので、結合は通常、ジャーナルが相対的に小さくなったシナリオに限定される。

【0067】

図１０Ａおよび図１０Ｂは、分散ストレージシステムにおいて、オブジェクトおよび関連付けられるメタデータを格納するための２つの実現例を示す。図１０Ａにおいて示される実現例は、完全に階層的（hierarchical）である。すなわち、すべてのオブジェクトは１つ以上のチャンクへ分割され、すべてのチャンクは１つ以上のブロックへ分割されている。なお、１つのチャンクまたは１つのブロックのみが存在する場合も、当該構造は階層的である。他方、図１０Ｂに示される実現例は単に、部分的に階層的である。この実現例において、いくつかのチャンクは、ブロックのリストを指す「スーパーチャンク」である。たとえばスーパーチャンクは、１００個のブロック、１０００個のブロック、またはそれ以上のブロックを有するブロックリストを有し得る。スーパーチャンクでないチャンクは単にブロックである。すなわち、チャンク識別子は、ブロックのリストではなく、オブジェクトデータの実際のストレージを指す。このハイブリッドアプローチは、（階層が必要でない）小さなオブジェクトと、ストレージ階層が非常により効率的である非常に大きいオブジェクトとの両方を含む分散ストレージシステムに有用であり得る。

【0068】

図２〜図４に示されるように、グローバルメタデータ１００２は、オブジェクトメタデータ２２８およびジャーナルメタデータ２３６を含む。いくつかの実現例において、各チャンクＩＤ３４６は、チャンクについてのデータを複合化するために使用される復号化キー１０４０を割り当てられる。これらの実現例では、同じ復号化キーは、複数のブロックへ分割されるチャンクについて、チャンクにおけるすべてのブロックに適用されることになる。各チャンクは、事実上一意である自身の復号化キー１０４０を有する。新しいキーが生成される場合、いくつかの実現例は一意性を保証するが、いくつかの実現例は新しいキーをランダムに生成し、キーの繰り返しが起こる可能性はあまり高くない。復号化キー１０４０は、新しいオブジェクトが格納される際に、新しいオブジェクトを暗号化するために使用される暗号キーに対応する。復号化キー１０４０は各オブジェクトチャンクにアクセスするために必要とされるので、復号化キーを削除することは、オブジェクトチャンクの「ソフトな（soft）」削除として使用され得る。復号化キーがなくなると、暗号化されたストレージは「ガーベッジ」となり、実際のデータはアクセス不能となる。これにより、ガーベッジコレクションアルゴリズムは、コンパクション同士の間により多くの時間を得ることが可能になり、ガーベッジコレクションプロセスは、実行されると、より多くのストレージスペースを回収することができる。

【0069】

さらに、（オープンとして示される）ジャーナル２３２と、対応するローカルメタデータ１００４とが図１０Ａにおいて示される。いくつかの実現例では、ジャーナル２３２についてのローカルメタデータ１００４は、ヘッダー７０２の一部として、ジャーナル自身に格納される。他の実現例では、ジャーナルについてのローカルメタデータ１００４は別個のファイルとして（またはデータベースなどに）格納され、ジャーナルに関連付けられる。非階層的なストレージについてのジャーナル２３２の構造は図７に関して上で示された。この実現例では、チャンクを格納するのではなく、ストレージの基本単位は、ブロック１０１６−１，１０１６−２，…，１０１６−Ｎといったブロック１０１６である。各実現例は典型的に、２メガバイト、４メガバイト、８メガバイトまたは１６メガバイトといったような最大のブロックサイズを特定する。

【0070】

上に示されるように、ローカルメタデータ１００４はジャーナル２３２のヘッダー７０２に格納され得るか、または、別々に格納され得る。各チャンク識別子３４６について、１つ以上のブロック識別子１００８を含む対応するブロックリスト１００６（典型的に一意のブロックリスト）が存在する。小さなチャンクについては、ブロックリスト１００６は、単一のブロック識別子１００８を含み得る。ローカルメタデータ１００４はさらに、各ブロックがジャーナル２３２内でどこに位置するかを特定するブロックインデックス１０１０を含む。いくつかの実現例において、ブロックの位置はオフセットおよびサイズによって特定される。いくつかの実現例におけるブロックオフセット１０１２は、ストレージスペース７１４の始めからのオフセットまたはジャーナルファイル２３２の始めについてのオフセットである。典型的に、ブロックサイズ１０１４はバイトで特定されるが、他の実現例は、サイズの代替的な基本単位（たとえば２バイト、４バイトまたは８バイト）を使用する。ローカルメタデータの１つの局面は、ジャーナルが別のインスタンスに移動またはレプリケートされる場合に、ローカルメタデータは変更しないということである。すなわち、あるチャンクについてのブロックリスト１００６は同じままであり、ブロックＩＤ１００８は同じままであり、ジャーナル内のブロックオフセット１０１２は同じままであり、ブロックサイズは同じままである。

【0071】

図１０Ｂは図１０Ａと同様であるが、部分的に階層的な構造を示す。図１０Ｂの部分的に階層的な構造において、グローバルメタデータ１００２は、各チャンクが通常のブロックか、または、ブロックのリストを参照する（すなわちスーパーチャンクである）かどうかを示す「スーパーチャンク」フィールド１０２０を含む。いくつかの実現例において、ほとんどのオブジェクトは小さく、単一のチャンクからなる。この場合、チャンクＩＤ３４６は、チャンク／ブロックインデックス１０２４においてブロックを直接的に識別する。すなわち、チャンクＩＤ３４６はチャンク／ブロックＩＤ１０２６である。したがって、スーパーチャンクでないチャンクの場合、ジャーナル２３２における対応するブロック１０１６についてオフセット１０２８およびサイズ１０３０を見つけるために、チャンク／ブロックインデックス１０２４における適切なレコードをルックアップするよう、チャンクＩＤ３４６が使用され得る。

【0072】

スーパーチャンクの場合、チャンクＩＤ３４６は、ローカルメタデータ１００４においてルックアップされ得る（スーパー）チャンクＩＤ１０２２である。スーパーチャンクＩＤ１０２２に対応するのはブロックリスト１００６であり、ブロックリスト１００６はブロックＩＤ１００８のセットを含む。この場合、ブロックＩＤの各々は、スーパーチャンクＩＤ１０２２についてのブロックリスト１００６においてブロックＩＤ１０２６の各々についてオフセット１０２８およびサイズ１０３０を識別するよう、チャンク／ブロックインデックス１０２４においてルックアップされ得る。上記のように、オフセット１０２８およびサイズ１０３０は、ジャーナル２３２のストレージスペース７１４において実際のブロックストレージの位置を識別する。したがって、スーパーチャンクはさらなるレベルの階層を有するが、グローバルメタデータ１００２に格納されるチャンクメタデータの量を低減する。これは、１つのインスタンスから別のインスタンスにシャードを移動させることをより容易かつ効率的にする。

【0073】

図１１Ａ〜図１１Ｄは、いくつかの実現例に従った、分散ストレージシステム２００においてオブジェクトレプリカの配置を管理する（１１０２）方法１１００を示す。この方法は、１つ以上のプロセッサおよびメモリを有する分散ストレージシステムの第１のインスタンス１０２において実行される（１１０４）。メモリは、１つ以上のプロセッサによる実行のための１つ以上のプログラムを格納する（１１０６）。いくつかの実現例において、方法１１００のすべてまたは部分は位置割当デーモン２０６によって実行される。いくつかの実現例において、分散ストレージシステムは複数のインスタンスを有する（１１０８）。これらの実現例のうちのいくつかでは、インスタンスの少なくともサブセットは、異なる地理的位置に存在する（１１０８）。いくつかの実現例において、各インスタンスはデータセンタに対応する。いくつかの実現例において、各データセンタは１つ以上のインスタンスを含む。

【0074】

第１のインスタンスでは、１つ以上のジャーナル２３２がオブジェクトチャンクの格納のためにオープンにされる（１１１０）。各ジャーナルは、単一のそれぞれの配置ポリシー２１２に関連付けられる（１１１２）。いくつかの実現例では、各配置ポリシーは、対象数のオブジェクトレプリカと、オブジェクトレプリカについての位置の対象セットとを特定する（１１２２）。いくつかの実現例では、配置ポリシー２１２は、データストア２２４のどのタイプがインスタンスのうちのいくつかにおいて使用されるべきであるか（たとえばディスクまたはテープ）を特定し得る。いくつかの実現例では、分散ストレージシステム２００は、どのジャーナルに各オブジェクトチャンク２３８が格納されているかを特定するオブジェクトメタデータ２２８（グローバルメタデータ１００２の部分）を含む（１１１４）。これは、図３〜図５、図１０Ａおよび図１０Ｂに関して以前に記載された。いくつかの実現例では、各それぞれのジャーナルは、それぞれのジャーナルに格納された各ブロックの位置を特定するブロックインデックス１０１０または１０２６を含む（１１１６）。これは、図７（非階層的）、図１０Ａおよび図１０Ｂにより詳細に記載された。特に、ジャーナル２３２内の各ブロック１０１６の位置は、ジャーナル自身に対して識別され、したがって、ブロックインデックス１０１０または１０２６は、ジャーナル２３２がどこに格納されるかにかかわらず正確である。たとえば、オフセットとしてジャーナル２３２内のブロック１０１６の位置を特定することによって、ブロック１０１６はリラティブアドレッシング（relative addressing）によってアクセスされ得る。

【0075】

開示された実現例は典型的に、各ジャーナルが格納される位置３７２を特定するジャーナルメタデータ２３６（グローバルメタデータ１００２の一部）を含む（１１１８）。これは、図３〜図５および図８に以前に記載された。

【0076】

オープンプライマリジャーナル２３２およびオープンセカンダリジャーナル２３４の分散は、利用可能なインスタンス１０２と、配置ポリシー２１２と、配置ポリシー２１２有する新しいオブジェクト２２６の予想される分散と、新しいオブジェクトがどこ（たとえばヨーロッパ、北米、アジア）からロードされるかと、利用可能なインスタンス１０２の各々での処理リソースと、さまざまなインスタンス同士間のネットワーク帯域幅とを含む多くのファクタに依存する。たとえば、多くのオブジェクトが、特定のインスタンスにて特定の配置ポリシーでアップロードされる場合、そのインスタンスでの同じ配置ポリシーについて、複数のジャーナルがオープンにされる（１１２０）。いくつかのシナリオにおいて、ロードバランシングに必要とされる場合、単一のインスタンス１０２において、同じ配置ポリシー２１２について、５個、１０個、またはそれ以上のオープンジャーナルが存在し得る。

【0077】

第１のインスタンス１０２では、少なくとも第１のオブジェクトチャンクを含む（１１２４）第１のオブジェクト２２６が受け取られる（１１２４）。これは、図６に関して上に記載された。第１のオブジェクト２２６は第１の配置ポリシー２１２に関連付けられており（１１２４）、したがって、オブジェクト２２６を含むオブジェクトチャンク２３８のすべては第１の配置ポリシー２１２に関連付けられる。第１のオブジェクトチャンクは、図１０Ａおよび図１０Ｂに関して上述したように、第１の複数のブロックを含む（１１２６）。いくつかの実現例において、プロセス１１００は、チャンクおよびブロックに既にパーティショニングされたオブジェクト２３８を受け取る（１１２４）。たとえば、オブジェクトをアップロードするクライアントデバイスによって分割が実行され得る。他の実現例において、プロセス１１００は、オブジェクトをストリームとして受け取り、格納された基準（たとえば対象ブロックおよびチャンクサイズ、利用可能なオープンジャーナル、利用可能なインスタンス、利用可能な帯域幅など）に従ってチャンクおよびブロックへオブジェクトを分割する。いくつかの実現例では、まだオブジェクトについてデータを受け取っている間、チャンクの動的割り当てが実行され、その一方、他の実現例は、全オブジェクトが受け取られた後にのみオブジェクトをチャンクおよびブロックへ分割する。

【0078】

チャンクおよびブロックの階層は、さまざまな態様で、オブジェクトのサイズのようなさまざまなファクタに基づいて形成され得る。いくつかの実現例において、階層は、アップロードプロセスの間に動的に構築される。たとえば、第１のオブジェクトチャンクが作成され、しきい値数のブロックがチャンクに割り当てられるまで、データのストリームが、第１のオブジェクトチャンクに割り当てられるブロックへ分割される。その時点において、第２のチャンクが作成され、新しいブロックが第２のチャンクに追加される。別の実現例では、データのストリームは最初は、ストレージのブロックとして格納され、ブロックがもはや存在しない場合、ブロックはチャンクへとグループ化される。

【0079】

いくつかの実現例において、すべてのオブジェクトチャンク２３８は１つ以上のブロックを含む（１１２８）。これは、図１０Ａに関して上で示された。いくつかの実現例において、グローバルメタデータ１００２は、各オブジェクトチャンク２３８がブロックまたはブロックのリストであるかどうかを特定するフィールド１０２０を含む（１１３０）。これは、図１０Ｂにおいて上で示される。いくつかのインスタンスにおいて、第１のオブジェクトチャンクはブロック（すなわちスーパーチャンク）のリストであり（１１３２）、第２のチャンクは通常のブロック（スーパーチャンクでない）である（１１３２）。

【0080】

第１の複数のブロック１０１６は、関連付けられる配置ポリシーが第１の配置ポリシー２１２とマッチする第１のジャーナル２３２に格納される（１１３４）。第１のジャーナル２３２は、配置ポリシーが第１の配置ポリシーとマッチするオブジェクトについてのブロックのみを格納する（１１３６）。

【0081】

受け取られたオブジェクトが特定されたサイズ（たとえばチャンクサイズまたはブロックサイズ）より大きい場合、オブジェクトは、複数のチャンク２３８および／または複数のブロック１０１６へ分割される。いくつかのインスタンスにおいて、第１のオブジェクト２２６は２つ以上のオブジェクトチャンクを含む（１１３８）。典型的に、第２のオブジェクトチャンクは、第１のオブジェクトチャンクと異なる（１１３８）。（単一のオブジェクト内に２つの同一のチャンクを有することは稀であるが、たとえば、オブジェクトが空のスペースの非常に大きな部分を有する場合に起こり得る。）いくつかの状況では、第２のオブジェクトチャンクが、関連付けられる配置ポリシーが第１の配置ポリシーとマッチする第１のジャーナルとは異なる第２のジャーナル２３２に格納される（１１４０）。第２のジャーナルは、配置ポリシーが第１の配置ポリシーとマッチするオブジェクトについてのオブジェクトチャンクのみを格納する（１１４０）。これにより、多くのチャンクを含むオブジェクトは、多くの異なるジャーナルにわたって分散されるチャンクを有し得る。

【0082】

いくつかの実現例では、そのプロセスは、各オブジェクトチャンクについてデータを暗号化し（１１４２）、グローバルメタデータにおける各オブジェクトチャンクについての復号化キーを格納する（１１４２）。これは、図１０Ａおよび図１０Ｂにおいて上で示された。いくつかの実現例では、チャンクが複数のブロックへ分割される場合、チャンク内のブロックの各々は同じ暗号キーで暗号化されるので、同じ復号化キーで複合化され得る。他の実現例において、各ブロックは、ブロックインデックス１０１０または１０２６の一部として格納され得るそれ自身の復号化キーを有する。グローバルメタデータ１００２に復号化キー１０４０を格納する実現例では、チャンクは単純に、復号化キーを削除すること（１１４４）によって事実上削除され得る。オリジナルチャンクについてデータを抽出する方法がないので、チャンクはアクセス不能である。これはいくつかの利点を提供する。第１に、チャンクを削除することは迅速かつ有効である。第２に、削除されたデータにアクセスする現実のリスクがないので、より効率的なガーベッジコレクションプロセスが実現され得る。特に、ガーベッジコレクションは適切な間隔でスケジューリングされ得、ディスクからストレージの物理的な削除（physical deletes of storage）をバッチ処理し得る。コンパクションはリソース集中的なプロセスであるので、多くの削除を一緒にバッチ処理する能力は、効率を劇的に増加させ得る。第３に、いくつかの実現例は、暗号化された「意味のないこと（gibberish）」は、意味のあるコンテンツに戻すように変換され得ないので、ストレージスペースの物理的な消去を必要としない。

【0083】

プロセス１１００は、第１のオブジェクトについてのグローバルメタデータを格納する（１１４６）。これは、図３〜図５、図１０Ａおよび図１０Ｂにおいて上で示された。グローバルメタデータ１００２は、第１のオブジェクトに対応するオブジェクトチャンクの第１のリストを含む（１１４８）。特に、第１のリストは、第１のオブジェクトチャンク２３８についてのオブジェクト識別子３３０を含む（１１５０）。グローバルメタデータ１００２はさらに、ジャーナルの各々についての位置と同様に各チャンクが格納されるジャーナルを識別する。

【0084】

グローバルメタデータ１００２に加えて、ローカルメタデータ１００４が各ジャーナル２３２について格納される。いくつかの実現例では、各ジャーナルについてのローカルメタデータ１００４は、ジャーナル２３２自身のヘッダー７０２に格納される。他の実現例において、ローカルメタデータ１００４はジャーナルとは別々に格納される。別々に格納される場合、各ジャーナルについてのローカルメタデータ１００４は別々に格納されてもよく（たとえば各ジャーナルに対応する異なるメタデータファイル）、または、ローカルメタデータは（たとえばデータベースにおいて）一緒にグループ化されてもよい。

【0085】

第１のインスタンスは、第１のオブジェクトチャンク２３８についてのローカルメタデータ１００４を格納する（１１５２）。ローカルメタデータ１００４は、第１の複数のブロックにおける各ブロックを識別するブロックリストを含む（１１５４）。なお、ブロックリストは、グローバルメタデータ１００２ではなく、ローカルメタデータ１００４に格納される。ローカルメタデータ１００４に格納されたブロックリスト１００６は、ブロックがどのように各ジャーナル内に割り当てられるかをトラッキングする。第１のジャーナル２３２についてのローカルメタデータは、第１のジャーナル２３２に関連付けられる（１１５６）。いくつかの実現例では、ジャーナルとのローカルメタデータの関連付けは、ジャーナルにローカルメタデータを格納することによって行なわれており、これによりジャーナルがより独立する（self-contained）。いくつかの実現例では、ジャーナル２３２についてのローカルメタデータは別々に（たとえば別個のファイルにおいて）格納され、（たとえば、ジャーナルの名称と、関連付けられるメタデータファイルの名称とにジャーナルＩＤ３７０を含むことによって）ジャーナルに関連付けられる。データベースにローカルメタデータを格納する実現例において、ジャーナルＩＤ３７０は典型的にメタデータテーブルについてのプライマリキーの一部である。

【0086】

オブジェクト２２６を受け取り、かつ、第１のジャーナル２３２にチャンク２３８を格納するこのプロセスは、関連付けられる配置ポリシー３３８が第１の配置ポリシー２１２にマッチする複数のオブジェクト２２６について、第１の終了条件が発生するまで繰り返される（１１５８）。いくつかの実現例では、第１の終了条件は、第１のジャーナルのサイズが予め規定されたしきい値を越える（１１６０）場合に発生する。いくつかの実現例では、第１の終了条件は、第１のジャーナルが予め規定された時間スパンの間オープンであった場合（１１６２）に発生する。いくつかの実現例は、さまざまな態様でサイズおよび時間を組み合わせる。たとえば、いくつかの実現例は、時間スパンおよびサイズ限界の両方を特定しており、終了条件は、上記のうちのいずれか一方が最初に発生することである。

【0087】

終了条件が発生した後、第１のジャーナルはクローズされ（１１６４）、これにより、如何なる付加的なブロックも第１のジャーナル２３２に格納されることを防止する。一般に、実現例は、第１のジャーナルをクローズする前に、同じ配置ポリシーについての他のジャーナル２３２がまだオープンである（または新しいジャーナルがオープンである）ことを確認する。新しいオブジェクトがいつでも到着し得るので、格納のためにオープンジャーナルを利用可能にしておくことが重要である。

【0088】

第１のジャーナル２３２がクローズされた後、ジャーナルはその配置ポリシーに従う。配置ポリシー２１２を満足させることは、ジャーナルレプリカを移動させること、ジャーナルレプリカの新しいコピーを作成すること、または、ジャーナルのレプリカを削除することを必要とし得る。いくつかの状況では、第１のジャーナル２３２は、配置ポリシー２１２に従って、分散ストレージシステム２００の第２のインスタンス１０２にレプリケートされる（１１６６）。（他の状況において、第１のジャーナルのレプリカは削除される。）プライマリオープンジャーナル２３２およびセカンダリオープンジャーナル２３４を有する実現例では、それらがひとたびクローズされると、２つの同等なクローズドジャーナル２３０が存在することになる。したがって、レプリケーション１１６６のためのソースとして、レプリカのいずれかが使用され得る。レプリケーション１１６６が発生する（たとえばトランザクションの一部として）と、第２のインスタンスにジャーナルのコピーが存在することを示すよう、第１のジャーナルについてのグローバルメタデータ１００２が更新される（１１６８）。他方、ローカルメタデータ１００４はレプリケーションによって変更されない（１１６８）。これは、図８、図１０Ａおよび図１０Ｂに関して上で記載された。

【0089】

ジャーナル２３０がクローズされた後、オブジェクトチャンク２３８が削除され得る。たとえば、オブジェクトはメール添付物に対応し得る。電子メールの受信者が電子メールを削除すれば、当該添付物についての格納分は削除され得る。ある期間の後、当該削除により各ジャーナル内にホールが存在するので、当該無駄にされているスペースを除去するようジャーナルをコンパクト化することが有用である。これは、揮発性メモリのフラグメンテーション、および、未使用スペースをより大きな連続するストレージへと統合するデフラグメンテーションのプロセスに類似している。

【0090】

格納されたオブジェクトチャンクが多くの（たとえば何百、何千または何百万の）異なるオブジェクトに対応し得るので、ジャーナルにおけるオブジェクトチャンクは、当該オブジェクトチャンクへの参照がもはや存在しない場合にのみ削除され得る。したがって、第１のクローズドジャーナル２３０がひとたび選択される（１１７０）と、プロセス１１００は、オブジェクトメタデータ２２８において参照が存在しない第１のクローズドジャーナル２３０に格納された１つ以上のオブジェクトチャンクを識別する（１１７２）。いくつかの実現例では、ガーベッジコレクションアルゴリズムは、クローズドジャーナルの各々をコンパクト化する（１１７４）よう、周期的に実行される。当該コンパクションプロセスは、格納されたブロックを連続的なストレージへと統合し（１１７４）、これにより、ジャーナル２３０のサイズを低減する。

【0091】

時間にわたって、より多くのオブジェクトチャンクが削除されると、ジャーナル２３０は小さくなり得る。多くの小さなジャーナルを管理することには、個々のオブジェクトを管理することと同様のオーバーヘッドが存在するので、ジャーナルの格納の利益は縮小される。この問題に対応するために、いくつかの実現例は、２つ以上のクローズドジャーナル同士を結合して（１１７６）単一の置換ジャーナルを形成し、当該２つ以上のジャーナルに以前に格納されたオブジェクトチャンクは置換ジャーナルに格納されているということを示すようオブジェクトメタデータ２２８を更新する（１１７６）。結合オペレーションは、完全に新しいジャーナルを形成することと、関連するオブジェクトのすべてについてメタデータを更新することとを必要とするので、結合は通常、ジャーナルが相対的に小さくなったシナリオに限定される。

【0092】

図１２は、いくつかの実現例に従った、図１０Ｂに関して以前に示されるように分散ストレージシステムにチャンクを格納する例を示す。この例において、２つのチャンク２３８−１および２３８−２が示される。チャンク２３８−１は、チャンクＩＤ３４６−１の通常のチャンクである（すなわちスーパーチャンクでない）。チャンク２３８−１は、通常のチャンクであるので、チャンク／ブロックインデックス１０２４において直接的にルックアップされ得る。この図において、チャンク／ブロックインデックス１０２４は、データが格納されるジャーナル２３２のヘッダー７０２に格納される。このチャンク／ブロックについては、オフセット１０２８はｙ（１０２８−ｙ）である。このオフセットを使用すると、対応するブロックＢ１０１６−Ｂは、ストレージスペース７１４において発見され得る。

【0093】

しかしながら、チャンク２３８−２は（スーパー）チャンクＩＤ３４６−２を有するスーパーチャンクである。ここで示されるように、スーパーチャンク２３８−２は、ブロックリストテーブル１００６におけるエントリを指す。各スーパーチャンクＩＤ１０２２について、複数の対応するブロックＩＤ１００８が存在する。図１２は、２つの対応するブロック１００８−１および１００８−２を示すが、非常に大きいオブジェクトの場合、単一のチャンクについて非常に多くのブロックが存在し得る。その後、ブロックＩＤ１００８−１および１００８−２は、ブロックについてオフセット１０２８−ｘおよび１０２８−ｚを発見するよう、チャンク／ブロックインデックス１０２４においてルックアップされる。最後に、オフセット１０２８−ｘおよび１０２８−ｚを使用して、対応するブロック１０１６−Ａおよび１０１６−Ｃはストレージスペース７１４に位置する。この例では、２つのブロックは連続しておらず、実際は、チャンク２３８−１についてのブロック１０１６−Ｂは、チャンク２３８−２についての２つのブロックを分離する。もちろん、各ブロックについての適切なデータのみが読み出されるように、各ブロックのサイズも使用される。これは、図１０Ｂに関して上で記載された。

【0094】

（チャンク２３８−１のような）通常のチャンクを許可しない実現例は完全に階層的である。また、チャンクとブロックとの間の割り当ては、実現例または他の動的なファクタに基づき変動する。たとえば、１００個のブロックを有する単一のチャンクまたは２５個のブロックを各々備えた４つのチャンクとして、同じオブジェクトが格納され得る。いくつかの実現例は、実際の使用からの経験的なフィードバックに基づいて、チャンクの数を変更する。

【0095】

説明の目的のためである上記の記載は、特定の実現例を参照して記載された。しかしながら、上記の例示的な議論は、網羅的であるように意図されておらず、または、本発明を開示されたそのままの形態に限定するよう意図されていない。上記の教示に鑑みて多くの修正例および変形例が可能である。上記の実現例は、本発明の原理およびその実際的な適用を最もよく説明するために選択および記載されたものであり、これにより他の当業者が、考慮される特定の使用に好適なさまざまな修正例とともに、本発明およびさまざまな実現例を最もよく利用するのが可能になる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図9C】

【図10A】

【図10B】

【図11A】

【図11B】

【図11C】

【図11D】

【図12】