JP2017510004A

JP2017510004A - 分散格納システムにおけるセッション管理

Info

Publication number: JP2017510004A
Application number: JP2016560580A
Authority: JP
Inventors: ヴィンセント，パラディープ
Original assignee: アマゾン・テクノロジーズ・インコーポレーテッド
Priority date: 2014-03-31
Filing date: 2015-03-31
Publication date: 2017-04-06
Anticipated expiration: 2035-03-31
Also published as: CA2944461C; US20150280959A1; KR20160140875A; CN106462544B; EP3126999A1; US10264071B2; KR101764559B1; CA2944461A1; EP3126999A4; WO2015153659A1; AU2015240904B2; CN106462544A; BR112016022636B1; SG11201608165PA; BR112016022636A2; AU2015240904A1; JP6371859B2; EP3126999B1

Abstract

特定のクライアントのセッション識別子の要求は、格納サービスのアクセスサブシステムから該サービスのメタデータサブシステムに送信される。クライアントセッションのメタデータが格納される永続性セッション格納場所に基づいたセッション識別子はアクセスサブシステムで受信される。セッション識別子はクライアントへのその送信の前にアクセスサブシステムでキャッシュされる。クライアントセッション中にクライアントからの特定の要求に応じてメタデータサブシステムによって生成されるロックステートインジケータは、アクセスサブシステムでキャッシュされてもよい。セッション中のクライアントからの後続格納要求は、キャッシュされたセッション識別子及びロックステートインジケータを使用し、アクセスサブシステムによって処理されてよい。【選択図】図５５

Description

多数の企業及び他の組織が、同じ場所に配置された（例えばローカルネットワークの一部として）、あるいは地理的に別個の複数の場所に配置された（例えば１つまたは複数の私設または公衆の中間ネットワークを介して接続された）コンピューティングシステム等により、自身の業務を支援するために、多数のコンピューティングシステムを相互接続するコンピュータネットワークを運用している。例えば、単一の組織が自身のために運用する私設データセンタ、及び顧客にコンピューティングリソースを提供する事業主体が運用する公衆データセンタ等、著しい数の相互接続されたコンピューティングシステムを収容するデータセンタは、今ではもう珍しくない。一部の公衆データセンタ運営者は、様々な顧客が所有するハードウェアに対しネットワークアクセス、電力、安全な設置施設を提供し、一方他の公衆データセンタ運営者は、顧客により利用可能なハードウェアリソースも含む「完全なサービス」施設を提供する。

いくつかの大きなプロバイダネットワークは、それぞれのＵＲＬを介してアクセス可能な任意のビットバケットとしてモデル化可能なブロックレベルデバイス（ボリューム）またはオブジェクトを実行するサービス等、様々な格納サービスを実施する。しかしながら、プロバイダネットワークのデータセンタで稼働する多数のアプリケーションは、様々な業界標準ファイルシステムインターフェイス等、より一般的な格納関連プログラム的インターフェイスのうちのいくつかの使用において、なおも制約に直面し得る。いくつかの業界標準ファイルシステムは、ネットワークアクセス可能サービスの大規模展開の前に設計され得たため、非同期演算インタラクション、個別コンポーネント及びネットワークパーティションにおける障害、またはネットワーク関連遅延が全て比較的に一般的である分散システムにおいて、実施することが容易ではない一貫性モデル及び他のセマンティックに対応し得る。

少なくともいくつかの実施形態による、分散ファイル格納サービスの高次概観図を提供する。少なくともいくつかの実施形態による、ファイル格納サービスを実施するための、プロバイダネットワークの複数の可用性コンテナにおけるリソースの使用を例示する。少なくともいくつかの実施形態による、隔離仮想ネットワークに対応付けられたネットワークアドレスが、格納サービスのアクセスサブシステムノードに割り当てられる構成を例示する。少なくともいくつかの実施形態による、ファイル格納サービスオブジェクトと、論理ブロックと、１つまたは複数のエクステントにおける物理ページとの間のマッピングを例示する。少なくともいくつかの実施形態による、データエクステント及びメタデータエクステントのレプリカグループの構成を例示する。少なくともいくつかの実施形態による、ファイル格納サービスのアクセスサブシステムノードにおけるメタデータのキャッシングに伴うインタラクション例を示す。少なくともいくつかの実施形態による、ファイルストアに対する、データ耐久性、パフォーマンス、及び論理対物理データマッピングに関するポリシーの異なる組み合わせの使用例を示す。図８ａは、少なくともいくつかの実施形態による、拡張縮小可能な分散ファイルシステム格納サービスを実施するために実行され得る構成及び管理関連動作の態様を例示するフロー図である。図８ｂは、少なくともいくつかの実施形態による、拡張縮小可能な分散ファイルシステム格納サービスにおいてクライアント要求に応じて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、分散ファイルシステム格納サービスにおいて複製ベース耐久性ポリシーを実施するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、分散ファイルシステム格納サービスのアクセスサブシステムノードにおいてメタデータをキャッシュするために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、書き込みオフセット及び書き込みサイズが時に物理格納の原子単位の境界と整列し得ないファイル格納サービスにおいて実行され得る読み出し‐変更‐書き込みシーケンスの例を示す。少なくともいくつかの実施形態による、エクステントレプリカグループに対するコンセンサスベースの複製ステートマシンの使用を例示する。少なくともいくつかの実施形態による、いくつかの種類の書き込み動作に使用され得る条件付き書き込みプロトコルに関わる例示的インタラクションを示す。少なくともいくつかの実施形態による、条件付き書き込みプロトコルを実施するために確立され得る例示的書き込みログバッファを示す。少なくともいくつかの実施形態による、分散ファイルシステム格納サービスにおいて条件付き書き込みプロトコルを実施するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、ファイル格納サービスにおいて分散トランザクションのコミットに至り得る例示的メッセージフローを示す。少なくともいくつかの実施形態による、ファイル格納サービスにおいて分散トランザクションのアボートに至り得る例示的メッセージフローを示す。少なくともいくつかの実施形態による、トランザクションのコーディネータとして指定されたノードを含む分散トランザクション参加ノードチェーンの例を示す。少なくともいくつかの実施形態による、ノードチェーンのノードのうちの１つにおける障害発生時に、分散トランザクションの完了を簡易化するために実行され得る例示的動作を示す。少なくともいくつかの実施形態による、ファイルシステム格納サービスにおいて分散トランザクションを調整するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、格納サービスのノードにおいてトランザクション準備メッセージを受信したことに応じて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、格納サービスのノードにおいてトランザクションコミットメッセージを受信したことに応じて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、格納サービスのノードにおいてトランザクションアボートメッセージを受信したことに応じて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、分散格納サービスにおける予約超過の格納エクステントの例を示す。少なくともいくつかの実施形態による、オンデマンドの物理ページレベル割り当て及びエクステント予約超過を実施する格納サービスのサブシステム間のインタラクションを例示する。図２６ａは、少なくともいくつかの実施形態による、空き格納領域閾値が指定されたエクステントを例示する。一方図２６ｂは、少なくともいくつかの実施形態による、空き格納領域閾値の侵害に起因するエクステントの拡張を例示する。少なくともいくつかの実施形態による、予約超過に対応するエクステントにおいてオンデマンドの物理ページ割り当てを実施するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、エクステント予約超過パラメータを動的に変更するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、可変ストライプサイズを使用してストライピングされるファイルストアオブジェクトの例を示す。少なくともいくつかの実施形態による、ファイルストアオブジェクトに使用され得るストライプサイズ決定シーケンスの例を示す。少なくともいくつかの実施形態による、ファイルストアオブジェクトに対しストライプサイズ決定及び／または統合決定を行うためにメタデータサブシステムにおいて考慮され得る要素例を示す。少なくともいくつかの実施形態による、可変ストライプサイズを使用してストライピングを実施するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、格納サービスオブジェクトの論理ブロックの全ての読み出し要求に対し相互に等しい優先権が与えられるスケジューリング環境における、論理ブロックに対する複数同時読み出し要求の進捗の例示的タイムラインを示す。少なくともいくつかの実施形態による、オフセットベースの輻輳制御ポリシーが使用されるスケジューリング環境における、格納サービスオブジェクトの論理ブロックに対する複数同時読み出し要求の進捗の例示的タイムラインを示す。図３５ａは、少なくともいくつかの実施形態による、格納サービスにおいてＩ／Ｏ要求をスケジューリングするために使用され得るトークンベースの輻輳制御機構の例を示す。図３５ｂは、少なくともいくつかの実施形態による、採用され得るオフセットベースのトークン消費ポリシーの例を示す。少なくともいくつかの実施形態による、格納サービスにおける輻輳制御のためのオフセットベース遅延の使用例を示す。少なくともいくつかの実施形態による、アクセスされている格納オブジェクトの種類、及び要求されるアクセスの様々な特徴によって決まり得る輻輳制御ポリシーの例を示す。少なくともいくつかの実施形態による、格納サービスにおいてＩ／Ｏ動作をスケジューリングするためにオフセットベースの輻輳制御を実施するように実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、名前変更動作を実行するために、格納サービスの複数のメタデータサブシステムノードにおいて実行される必要があり得るメタデータ変更の例を示す。少なくともいくつかの実施形態による、同時名前変更動作に対するデッドロック回避機構の使用を例示する。少なくともいくつかの実施形態による、名前変更動作のために格納サービスにおいて特定され得る、２つの可能なロック順序のうちの第１ロック順序に基づいて、第１名前変更ワークフローを実施するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、名前変更動作のために格納サービスにおいて特定され得る、２つの可能なロック順序のうちの第２ロック順序に基づいて、第２名前変更ワークフローを実施するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、名前変更ワークフローに参加する１対のメタデータサブシステムノードのうちの１つのメタデータサブシステムノードにおける障害に応じて実行され得る復旧動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、名前変更ワークフローに参加する１対のメタデータサブシステムノードのうちのもう１つのメタデータサブシステムノードにおける障害に応じて実行され得る復旧動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、ファイルストア名前空間管理に使用され得るハッシュベースの有向非巡回グラフ（ＤＡＧ）の例を示す。少なくともいくつかの実施形態による、ファイル名に取得されたハッシュ値の連続サブシーケンスを使用して、ＨＤＡＧをトラバースする技術を例示する。少なくともいくつかの実施形態による、名前空間にエントリを挿入する試みから生じ得る２種類のＨＤＡＧノード分割のうちの第１種のＨＤＡＧノード分割の例を示す。少なくともいくつかの実施形態による、名前空間にエントリを挿入する試みから生じ得る２種類のＨＤＡＧノード分割のうちの第２種のＨＤＡＧノード分割の例を示す。少なくともいくつかの実施形態による、２種類のＨＤＡＧノード削除動作のうちの第１種のＨＤＡＧノード削除動作の例を示す。少なくともいくつかの実施形態による、２種類のＨＤＡＧノード削除動作のうちの第２種のＨＤＡＧノード削除動作の例を示す。少なくともいくつかの実施形態による、第１種のＨＤＡＧノード分割を生じる名前空間へのエントリの挿入に応じて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、第２種のＨＤＡＧノード分割を生じる名前空間へのエントリの挿入に応じて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、名前空間からエントリの削除に応じて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、分散格納サービスにおけるセッション指向のファイルシステムプロトコルのために保持され得るメタデータの二局面を例示する。少なくともいくつかの実施形態による、分散格納サービスのサブコンポーネント間におけるクライアントセッションのメタデータ関連インタラクションの例を示す。少なくともいくつかの実施形態による、分散格納サービスにおけるクライアントセッションのリース更新の代替的手法を例示する。図５７ａ及び５７ｂは、少なくともいくつかの実施形態による、分散格納サービスにおけるセッション指向のファイルシステムプロトコルのためのロックステート管理の代替的手法を例示する。少なくともいくつかの実施形態による、分散格納サービスにおいて実行され得るクライアントセッションメタデータ管理動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、分散格納サービスにおいて実行され得るクライアントセッションリースの更新動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、分散格納サービスのために負荷分散層が構成されたシステムを例示する。少なくともいくつかの実施形態による、負荷分散ノードと、分散格納サービスの複数のアクセスサブシステムノードとの間の例示的インタラクションを示す。少なくともいくつかの実施形態による、行われた接続試行の回数により変わり得る接続受諾基準の例を示す。少なくともいくつかの実施形態による、複数のリソースに対応付けられた作業負荷レベル、並びに接続確立試行回数に依存し得る接続受諾基準の例を示す。少なくともいくつかの実施形態による、分散格納サービスにおいて試行回数に基づき接続分散を実施するために実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、アクセスノードピアグループのメンバーの作業負荷インジケータに基づいて、クライアント接続の再分散を試み得る分散格納サービスのアクセスサブシステムの例を示す。少なくともいくつかの実施形態による、アクセスサブシステムノードにおいて使用され得る接続受諾及び再分散基準の例を示す。少なくともいくつかの実施形態による、接続再分散を実施するために、分散格納サービスのアクセスサブシステムにおいて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態による、接続再分散イベントを越えてクライアントセッションを保持するために、分散格納サービスにおいて実行され得る動作の態様を例示するフロー図である。少なくともいくつかの実施形態において使用され得る例示的コンピューティングデバイスを示すブロック図である。

本明細書において実施形態は、いくつかの例示的実施形態及び例示的図面として説明されるが、実施形態は説明される実施形態または図面に限定されないことを、当業者は認識するであろう。図面及びその詳細説明には、実施形態を開示される特定の形態に限定する意図はなく、それとは逆に、添付の請求項により定義される趣旨と範囲に入る全ての変更、均等物、及び代替案を含める意図があることは理解されよう。本明細書において使用される見出しは、構成目的でのみ使用され、説明または請求項の範囲を限定するために用いられることを意図しない。本出願を通して使用される英単語「ｍａｙ」は、義務的な意味（すなわち「〜しなければならない」という意味）ではなく、許容的な意味（すなわち「〜する可能性がある」という意味）で使用される。同様に、英単語「ｉｎｃｌｕｄｅ」、「ｉｎｃｌｕｄｉｎｇ」、及び「ｉｎｃｌｕｄｅｓ」は「含む」ことを意味するが、その対象に限定されない。

高可用性かつ高耐久性の拡張縮小可能ファイル格納サービスの方法及び装置の様々な実施形態が説明される。少なくともいくつかの実施形態において、ファイル格納サービスは、各個別ファイルが非常に大きいデータ量（例えばペタバイト）を含み得るファイルに対する幾千のクライアントによる共有アクセスに、ファイルのサイズ及び／または同時ユーザの数とは無関係に目標とするパフォーマンス、可用性、及び耐久性のレベルで対応するように設計され得る。１つまたは複数の業界標準ファイルシステムインターフェイスまたはプロトコルは、様々なバージョンのＮＦＳ（ネットワークファイルシステム）、ＳＭＢ（サーバメッセージブロック）、ＣＩＦＳ（共通インターネットファイルシステム）等のサービスにより対応され得る。従って、少なくともいくつかの実施形態において、分散ファイル格納サービスが対応する一貫性モデルは、業界標準プロトコルが対応するモデルと少なくとも同じくらい強力であり得る。例えば当サービスは逐次一貫性に対応し得る。逐次一貫性モデルを実施する分散システムにおいて、複数の実行エンティティ（例えば分散システムのノードまたはサーバ）で集合的に実施された動作実行の結果は、全ての動作がある順序で実行されたかのように、同一であることが期待される。ファイル格納サービスは、ファイルストア容量及びパフォーマンス等のオンデマンド拡張縮小を要求するメディア的、経済的、及び科学的ソリューション等の、ファイルコンテンツ取り扱いアプリケーション（例えばウェブサーバファーム、ソフトウェア開発環境、及びコンテンツ管理システム）、高性能コンピューティング（ＨＰＣ）アプリケーション、及び「ビッグデータ」アプリケーションといった多種多様なアプリケーションによる使用のために設計され得る。「ファイルストア」という用語は本明細書において、ファイルシステムの論理的均等物を示すために使用され得る。例えば、所定のクライアントは、２つの異なるＮＦＳ準拠ファイルストアＦＳ１及びＦＳ２を作成し得る。ＦＳ１のファイルは、マウント可能なルートディレクトリのサブディレクトリの１つの集合内に格納され、ＦＳ２のファイルは、別のマウント可能なルートディレクトリのサブディレクトリの集合内に格納される。

少なくともいくつかの実施形態において、ハイレベルな拡張縮小性を可能にすることを支援するために、当サービスにはモジュラアーキテクチャが使用され得る。例えば、一実施態様において、複数のマルチテナント型格納ノードを備える物理格納サブシステムは、ファイルストアコンテンツに使用され、一方自身のメタデータノードの集合を有する論理上異なるメタデータサブシステムは、ファイルストアコンテンツを管理するために使用され得る。例えば、メタデータに対するパフォーマンス、耐久性、及び／または可用性の要件は、少なくともいくつかの事例においてデータに対する該当要件とは異なり得る（例えばメタデータに対する該当要件はデータに対する該当要件よりも厳しい）という事実により、メタデータとデータの論理的分離は動機付けられ得る。メタデータノード及び格納ノードとは異なる自身のアクセスノードの集合を有するフロントエンドアクセスサブシステムは、クライアントが業界標準インターフェイスを介してファイルストアの作成、読み出し、更新、変更、及び削除を要求することを可能にするネットワークエンドポイントを公開する責任、そして接続管理、負荷分散、認証、認可、及びクライアントインタラクションに伴う他のタスクを処理する責任を担い得る。いくつかの実施形態において、サブシステムのうちのいずれか１つに対し、例えばアクセスサブシステム、メタデータサブシステム、または格納サブシステムに対し、リソースは独立して展開され、その他のサブシステムにおける対応展開変更を要求することはない。例えば、アクセスサブシステムにおいて潜在的パフォーマンスボトルネック等のトリガー条件が特定された場合、またはアクセスサブシステムノードのある集合がネットワーク停止または他の障害を経験した場合、格納サブシステムまたはメタデータサブシステムに影響を及ぼすことなく、かつクライアント要求の流れを休止することなく、追加アクセスサブシステムノードがオンライン化され得る。様々な種類のトリガー条件に応じて、同様の展開変更が他のサブシステムにおいても行われ得る。いくつかの実施形態において、特にアクセスサブシステムノードは、アクセスノード障害からの復旧が特別効率良くあり得るように、略ステートレスに実行され得る。

少なくともいくつかの実施形態において、ファイルストアメタデータオブジェクト（例えばディレクトリエントリ、リンク等の属性を表すデータ構造）のコンテンツ自体は、格納サブシステムにより管理されるデバイス上に格納され得る。しかし後述されるように、いくつかの事例において、メタデータに使用されている格納オブジェクトに適用されるポリシーとは異なるポリシーが、データに使用されている格納オブジェクトに適用され得る。このような実施形態において、メタデータサブシステムノードは、例えば、メタデータ管理ロジックを実行する様々な実行プロセスまたは実行スレッドを含み、格納サブシステムにおいてメタデータコンテンツの格納を調整し得る。いくつかの実施形態において、所定の格納サブシステムノードは、回転磁気ディスクを採用する複数のデバイス、及びソリッドステートドライブ（ＳＳＤ）を採用する複数のデバイス等、いくつかの異なる種類の格納媒体を含み得る。いくつかの実施形態において、所定の格納サブシステムノードは、メタデータとデータの両方を、それぞれ異なる格納デバイスに、または同じ格納デバイス上に格納し得る。「ファイルストアオブジェクト」という用語は本明細書において、格納サービスのクライアントが通常見えるファイル、ディレクトリ等のデータオブジェクト、並びにデータオブジェクトを管理及び格納するために使用される内部メタデータ構造（例えば後述される論理ブロック、物理ページ、及びエクステントの間のマッピングを含む）を、集合的に指すために使用され得る。

少なくともいくつかの実施形態において、分散ファイル格納サービスは、プロバイダネットワークのリソースを使用して構築され、主としてプロバイダネットワーク内の他のエンティティからの格納要求を遂行するように設計され得る。インターネット及び／または他のネットワークを介してアクセス可能な１つまたは複数のネットワークアクセス可能サービス（様々な種類のクラウドベースのコンピューティングサービスまたは格納サービス等）を、クライアントの分散集合に提供するために、企業または公的機関等の事業体が構築したネットワークは、本明細書においてプロバイダネットワークと称され得る。当該サービスのいくつかは、よりハイレベルなサービスを構築するのに使用され得る。例えば、コンピューティングサービス、格納サービス、またはデータベースサービスは、コンテンツ配信サービスまたはストリーミングデータ処理サービスのブロックを構築することに使用され得る。プロバイダネットワークのサービスのうちの少なくともいくつかは、クライアント使用のために、「インスタンス」と呼ばれるサービス単位にパッケージ化され得る。例えば、仮想化コンピューティングサービスによりインスタンスが生成された仮想マシンは、「演算インスタンス」と表され得る。プロバイダネットワークのこのような演算インスタンスが実行されるコンピューティングデバイスは、本明細書において「インスタンスホスト」またはより簡潔に「ホスト」と称され得る。所定のインスタンスホストはいくつかの演算インスタンスを含み、１つまたは複数のクライアントのアプリケーションを実行するために、特定のインスタンスホストにおいて演算インスタンスの集まりが使用され得る。いくつかの実施形態において、例えば、格納サービスのアクセスサブシステムに適切なネットワークアドレスを割り当てること、仮想コンピューティングサービスに使用される認可／認証プロトコルを実施すること等の結果として、ファイル格納サービスは、プロバイダネットワークの演算インスタンスのある部分集合（または全て）からアクセス可能になり得る。いくつかの実施形態において、プロバイダネットワークの外部のクライアントにもファイル格納サービスへのアクセスが提供され得る。様々な実施形態において、プロバイダネットワークサービスのうちの少なくともいくつかは、利用ベースの価格設定ポリシーを実施し得る。例えば、演算インスタンスを使用した時間の長さに少なくとも一部基づいて、または演算インスタンスから送られた様々な種類の要求の数に少なくとも一部基づいて、顧客に対し演算インスタンスの課金が行われ得る。少なくともいくつかのこのような実施形態において、ファイル格納サービスも、少なくともいくつかのカテゴリのクライアント要求に対して利用ベース価格設定を採用し得る。例えば、当該サービスは、所定の顧客のために完了した特定のファイルシステムインターフェイス要求の記録を保持し、当記録に基づいて顧客に対する請求額を生成し得る。

ファイルストアサービスは、いくつかの実施形態において、例えば多数の異なる複製技術のうちのいずれかを使用して、ハイレベルなデータ耐久性を維持し得る。例えば、一実施形態において、ファイルストアデータ及びメタデータは、エクステントと呼ばれる格納単位を使用して物理的に格納され、エクステントのコンテンツは、様々な物理格納デバイスにおいて複製され得る。エクステントのコンテンツは、異なる物理格納デバイスにおける物理コピーと区別するために、「論理エクステント」と本明細書において称され得る。物理コピーは、「エクステントレプリカ」、「レプリカグループメンバー」または「小エクステント」もしくは「レプリカグループ」と称され得る。一実施態様において、例えば、ファイル（またはメタデータオブジェクト）は、各論理ブロックが１つまたは複数の物理データページにマッピングされている一連の論理ブロックとして組織され得る。論理ブロックはストライピングの単位とみなさるため、少なくともいくつかの実施態様において、同一ファイル（または同一メタデータ構造）の２つの異なる論理ブロックのコンテンツが同じ格納デバイスに格納される可能性は低くあり得る。所定の論理エクステントの各レプリカは、複数の物理データページを含み得る。いくつかの実施形態において、消失訂正符号ベースのエクステントレプリカが使用され得る一方、他の実施形態においては、完全複製等の別の複製技術が使用され得る。少なくとも一実施形態においては、消失訂正符号と完全複製の組み合わせが使用され得る。クライアントからの所定の変更要求は、対応ファイルストアオブジェクトまたはメタデータに使用されている複製ポリシーの特性によって、それぞれの格納デバイス及び／またはそれぞれの格納サブシステムノードにおける複数の物理変更へと適宜変換され得る。いくつかの実施形態において、レプリカグループのエクステントレプリカのうちの１つまたは複数は、マスタレプリカとして指定され、例えばコンセンサスベースの複製ステートマシンを使用して、現行マスタを提供する格納サービスノードにより、エクステントに対する更新が整合され得る。このような格納サービスノードは、マスタレプリカを格納するエクステントに関して、本明細書において「マスタノード」または「リーダ」と称され得る。一実施態様において、所定の論理エクステントのＮ個のエクステントレプリカが保持されている場合、レプリカのクォーラムＭ（ＭはＮ／２以上）が必要となり、このようなクォーラムは、特定の更新がコミットされる前に、リーダ／マスタノードにより開始される更新プロトコルを使用して取得され得る。一実施形態において、一部のエクステントは、ファイルコンテンツまたはデータに全体的に使用され、他のエクステントは、メタデータに独占的に使用され得る。別の実施形態において、所定のエクステントは、データとメタデータの両方を格納し得る。いくつかの実施態様において、所定のファイルストアのステート変化を示すログ記録を複製するのに、コンセンサスベースプロトコルが使用され、当該ステートのコンテンツは、複数のエクステントを使用して複製され得る（例えば完全複製または消失訂正符号複製のどちらかを使用して）。様々な実施形態において、少なくともいくつかの種類の読み出し動作の一貫性を確保するために、複製ステートマシンも使用され得る。例えば、単一クライアント読み出し要求は、様々なエクステントにおける複数の物理読み出し動作（例えばメタデータ及び／またはデータの物理読み出し動作）を実際に要し、複製ステートマシンの使用により、このような分散読み出しが、対象ファイルストアの読み出し一貫性要件を破らないことが保証され得る。

後述される異なる実施形態において、データ及びメタデータの論理ブロック、物理ページ、及び／またはエクステントのサイズ及びこれらの関係を決定するために、様々な異なる割り当て及びサイズ決定ポリシーが使用され得る。例えば、一簡潔実施態様において、ファイルは複数の固定サイズ（例えば４メガバイト）の論理ブロックを含み、各論理ブロックは複数の固定サイズ（例えば３２キロバイト）の物理ページを含み、そして各エクステントは固定数のページを格納するのに十分な格納領域（例えば１６ギガバイト）を備え得る。別の実施形態において、異なる論理ブロックはサイズにおいて異なり得る、または物理ページはサイズにおいて異なり得る、またはエクステントはサイズにおいて異なり得る。いくつかの実施形態において、エクステントは動的にサイズ変更（例えば増大または縮小）され得る。いくつかの実施形態において、論理ブロックに静的割り当てが使用され（例えば、ブロックに対する第１書き込みに応じて、ブロックのサイズに対する書き込みペイロードのサイズに関係なく、論理ブロック全体の全ての物理格納領域が割り当てられ得る）、一方他の実施形態においては動的割り当てが使用され得る。論理ブロック構成及び対応物理格納領域割り当てを統御する様々な技術及びポリシーが、さらに詳しく後述される。いくつかの実施形態において、ファイル格納サービスにより管理される異なるファイルストアは、異なるブロック／ページ／エクステントサイズ決定及び構成ポリシーを実施し得る。いくつかの事例において、クライアントからの所定の書き込み動作は、使用されているファイルシステムインターフェイスがクライアントに指定を許可する書き込みサイズに応じて、ページ全体の変更ではなく、ページの一部のみの変更をもたらし得る。所定の実施態様において、格納サブシステムが対応する書き込みに関して物理ページが最小レベルの原子性ではあるが、書き込み要求は任意のデータ量を対象とすることが可能である場合（すなわち書き込みは、ページ境界に合っている必要はなく、整数ページの全てのコンテンツを変更する必要もない場合）、いくつかの書き込みは読み出し‐変更‐書き込みシーケンスとして、格納サービス内部で取り扱われ得る。いくつかのこのような実施形態においてページ境界を越えない書き込みに対し採用され得る楽観的条件付き書き込み技術に関する詳細が、下記に提供される。一般に各格納デバイス及び／または格納サービスノードは、少なくともいくつかの実施形態において、複数の異なる顧客の動作に対応し、及び／または複数の異なる顧客のデータを格納し得る。

一般に、顧客から受信した単一ファイルストア動作要求のために読み出しまたは変更される必要があり得るメタデータ及び／またはデータは、複数の格納サービスノードに分配され得る。例えば、削除動作、名前変更動作等は、いくつかの異なる格納デバイス上に配置されたメタデータ構造の複数の要素に対し、更新を要求し得る。逐次一貫性モデルに従って、少なくとも一実施形態において、１つのメタデータサブシステムノードにおける第１メタデータ変更及び別のメタデータサブシステムノードにおける第２メタデータ変更を含む単一クライアント要求に応えるために、ファイルシステムメタデータ変更グループを含む原子メタデータ動作が実行され得る。逐次一貫性に対応する様々な分散更新プロトコルが、異なる実施形態において使用され得る。例えば、さらに詳しく後述される分散トランザクション機構が、少なくともいくつかの実施形態において、そのような複数ページ、複数ノード、または複数エクステントの更新に使用され得る。いくつかの実施形態において、当然使用されている複製戦略に応じて、メタデータ変更のそれぞれが順番に、複数のエクステントレプリカに対する更新を伴い得る。

いくつかの実施形態において、オブジェクト名変更プロトコル、接続寿命を考慮した負荷分散技術、名前空間管理技術、クライアントセッションメタデータキャッシング、オフセットベースの輻輳制御ポリシー等の使用といった、ファイル格納サービスの様々な態様に伴う最適化技術が採用され得る。格納サービスのこれらの特徴に関する詳細は、様々な図面の説明と合わせて下記に提供される。

ファイル格納サービス概要
図１は、少なくともいくつかの実施形態による、分散ファイル格納サービスの高次概観図を提供する。示されるように、格納サービス１０２を含むシステム１００は、格納サブシステム１３０と、メタデータサブシステム１２０と、アクセスサブシステム１１０の少なくとも３つのサブシステムに論理的に分割され得る。各サブシステムは、格納サブシステム１３０の格納ノード（ＳＮ）１３２Ａ、１３２Ｂと、メタデータサブシステム１２０のメタデータノード（ＭＮ）１２２Ａ、１２２Ｂと、アクセスサブシステム１１０のアクセスノード（ＡＮ）１１２Ａ、１１２Ｂ等、複数のノードを備え得る。各ノードは例えば、いくつかの実施形態において、各自の物理サーバまたは仮想化サーバにおいて実行されるプロセスまたはスレッドの集合として実装され得る。少なくともいくつかの実施形態において、任意の所定サブシステムにおけるノードの数は、他のサブシステムにおけるノードの数とは関係なく変更可能であるため、サブシステムのうちのいずれかにおいて必要に応じた追加リソースの展開（並びにサブシステムのいずれかにおいて同様のリソースの独立削除）が可能である。用語「アクセスサーバ」、「メタデータサーバ」、及び「格納サーバ」は、それぞれ用語「アクセスノード」、「メタデータノード」、及び「格納ノード」の均等物として本明細書において使用され得る。

描かれた実施形態において、格納ノード１３２は、例えばＳＳＤと回転ディスクのある組み合わせを使用して、エクステント１３４（格納ノード１３２Ａにおけるエクステント１３４Ａと１３４、及び格納ノード１３２Ｂにおけるエクステント１３４Ｋと１３４Ｌ等）を格納する責任を担い得る。例えば物理格納デバイスのある集合において複数のギガバイト（一般的ではあるが必ずしもではない）の連続する格納領域を含み得るエクステントは、いくつかの実施形態において、格納複製の単位を表し得る。従って、任意の所定論理エクステントの多数の物理レプリカが格納され得る。各エクステントレプリカは、いくつかの実施形態において、多数の物理ページとして組織され得る。当該ページは、格納サブシステム内で読み出しまたは書き込みが実行される最小単位を表す。図４に関して後述されるように、所定のファイルストアオブジェクト（例えばファイルまたはメタデータ構造）は、論理ブロックの集合として組織され、各論理ブロックはデータエクステント内のページの集合にマッピングされ得る。ファイルストアオブジェクトのメタデータは、それ自体が論理ブロック（データの対応論理ブロックとはサイズが異なる可能性のある論理ブロック）の集合を備え、別のエクステント１３４のページに格納され得る。少なくともいくつかの実施形態において、エクステントレプリカに対する更新を管理するために、複製ステートマシンが使用され得る。

アクセスサブシステム１１０は、描かれた実施形態において、ファイルシステムＡＰＩ（アプリケーションプログラムインターフェイス）１４０等、１つまたは複数のファイルシステムインターフェイスをクライアント１８０に対し提示し得る。少なくともいくつかの実施形態において、さらに詳しく後述されるように、負荷分散装置の集合（例えば格納サービス自体とは関係なく構成され得るソフトウェアまたはハードウェアデバイス）は、格納サービスのクライアントとアクセスサブシステムの間の仲介として機能し得る。いくつかの事例において、負荷分散機能性の少なくともいくつかの態様は、アクセスサブシステム自体の中で実施され得る。少なくともいくつかの実施形態において、アクセスサブシステムノード１１２は、クライアント１８０が同時に使用する好適なネットワーク構造内に確立されたサービスエンドポイントを表し得る。図３に関して後述されるように、いくつかの実施形態において、隔離仮想ネットワークに対応付けられた特別ネットワークアドレスが、ＡＮ１１２に割り当てられ得る。ＡＮ１１２は、例えばクライアントのネットワーク識別並びにユーザ識別に基づいて、クライアント入接続を認証し得る。いくつかの事例において、ＡＮは、アクティブディレクトリサービスまたはケルベロスと同様の識別／認証サービスとインタラクトし得る。分散ファイル格納サービス１０２（ＮＦＳｖ４及びＳＭＢ２．１）が対応し得るいくつかのファイルシステムプロトコルは、例えばロック及びオープンファイルの識別子に係るステートを、ファイルサーバが保持することを要求し得る。いくつかの実施形態において、ロック及びオープンファイルのステートを含む持続的サーバステートは、アクセスサブシステムではなく、メタデータサブシステム１２０により取り扱われ、その結果、アクセスサブシステムは、必要に応じて拡張及び縮小可能な略ステートレスなサーバ隊としてみなされ得る。いくつかの実施形態において、図６に関して後述されるように、ＡＮ１１２は、様々なファイルストアオブジェクトに係るメタデータステートをキャッシュし、キャッシュしたメタデータを使用して、少なくともいくつかの内部Ｉ／Ｏ要求を、メタデータノードとのインタラクションを要求することなく直接格納ノードへ送り得る。

メタデータサブシステム１２０は、描かれた実施形態において、様々な種類のファイルストアメタデータ構造を管理する責任を担い得る。ファイルストアメタデータ構造には、例えばｉノード、アクセスコントロールリスト（ＡＣＬ）等のファイル／ディレクトリ属性、リンク数、変更回数、実ファイルサイズ、格納サブシステムページを示す論理ブロックマップ等が含まれる。さらに、メタデータサブシステムは、いくつかの実施形態において、ファイルストアオブジェクトのオープン／クローズステート、及び様々なファイルストアオブジェクトのロックを記録し得る。メタデータサブシステム１２０は、ＮＦＳクライアントが求めるクローズ対オープンセマンティック等、所望するファイルストアオブジェクトの一貫性セマンティックを維持するように、動作の順序設定及び調整を行い得る。メタデータサブシステムはまた、例えば後述の分散トランザクション技術を使用して、名前変更、削除、切り捨て、及び付加等の複数のメタデータ要素を伴い得る動作にわたる逐次一貫性を確保し得る。メタデータサブシステム１２０は、論理的に格納サブシステム１３０から独立しているが、少なくともいくつかの実施形態において、永続性メタデータ構造は、格納サブシステムに格納され得る。このような実施形態において、メタデータ構造は格納サブシステムに物理的に格納され得るが、メタデータサブシステムノードは、使用する特定の格納ノードの同定、メタデータに対する格納動作の調整または順序設定等のタスクの責任を担い得る。少なくともいくつかの実施形態において、メタデータサブシステムは、格納サブシステムのコンセンサスベースステート複製機構等、いくつかの実施形態における格納サブシステムにより採用されるステート管理技術のうちのいくつかを再利用し得る。

ファイル格納サービスのプロバイダネットワーク実施態様
先に述べたように、いくつかの実施形態において、分散格納サービスは、プロバイダネットワークのリソースを使用して実施され、そしてプロバイダネットワークの演算インスタンスにおいて稼働しているアプリケーションまたはクライアントによるファイル関連動作のために使用され得る。いくつかの実施形態において、プロバイダネットワークは、複数の地理的領域に編制され、各領域は、本明細書において「可用性ゾーン」とも称され得る１つまたは複数の可用性コンテナを含み得る。そして可用性コンテナは、所定の可用性コンテナ内のリソースが他の可用性コンテナにおける障害から隔離されるように（例えば電力関連設備、冷却設備、及び物理的安全構成要素等の独立インフラストラクチャ構成要素と共に）設計された１つまたは複数の別個の場所またはデータセンタを含み得る。１つの可用性コンテナにおける障害は、その他の可用性コンテナにおける障害に至ると予期され得ないため、リソースの可用性プロファイルは、別の可用性コンテナにおけるリソースの可用性プロファイルから独立するように企図される。様々な種類のアプリケーションは、それぞれの可用性コンテナにおいて複数のアプリケーションインスタンスを開始することにより、単一の場所における障害から守られ得る。格納サービスの様々なサブシステムのノードもまた、いくつかの実施形態において、例えばサービスの可用性／可用時間目標、及び／または様々なファイルストアに対するデータ冗長性要件に従って、いくつかの異なる可用性コンテナにわたり分配され得る。同時に、いくつかの実施態様において、同一地理的領域内に存在するリソース（分散ファイル格納サービスに使用されているホストまたは格納デバイス等）の間に、安価で低遅延のネットワーク接続が提供され、同一可用性コンテナのリソース間のネットワーク送信はさらに速くあり得る。一部のクライアントは、自身のアプリケーションの様々なコンポーネントが稼働する正確な場所に対し所望する制御度を維持するために、自身のファイルストアに使用されているリソースのうちの少なくともいくつかが備蓄及び／またはインスタンス化される場所を、例えば地域レベル、可用性コンテナレベル、またはデータセンタレベルで、特定したいと所望し得る。他のクライアントは、例えばパフォーマンス、高可用性等のクライアント要件をリソースが満たす限り、自身のリソースが備蓄またはインスタンス化される正確な場所に関心が薄くあり得る。

少なくともいくつかの実施形態において、所定のデータセンタ内のリソースは、所期可用性の差または障害許容力レベルに基づいて、サブグループにさらに分割され得る。例えば、データセンタにおける１つまたは複数のサーバラックは、少なくともいくつかの事例において、ラック内の相関障害の可能性が異なるラックにまたがる相関障害の可能性よりも高くあり得るため、低レベル可用性コンテナとして指定され得る。少なくともいくつかの実施形態において、格納サービスの様々なコンポーネントまたはノードをどこでインスタンス化するかを決定する時、パフォーマンス目標及び耐久性目標と共に、説明された様々なレベルの可用性包含（例えば地域レベル、データセンタレベル、またはラックレベル）の任意の組み合わせが考慮され得る。従って、いくつかの種類の格納サービスコンポーネントに対し、ラックレベルの冗長性／複製は十分であるとみなされ得るため、一般に、同じ機能を提供する（または同一データ／メタデータの複製を格納する）異なるコンポーネントに、異なるラックが使用され得る。他のコンポーネントに対し、冗長性／複製が、同様にまたは代わりに、データセンタレベルまたは地域レベルで実施され得る。

図２は、少なくともいくつかの実施形態による、ファイル格納サービスを実施するための、プロバイダネットワーク２０２の複数の可用性コンテナ２１２におけるリソースの使用を例示する。描かれた実施形態において、３つの可用性コンテナ２１２Ａ、２１２Ｂ、２１２Ｃが示される。それぞれの可用性コンテナが格納サービスの複数の格納ノード、メタデータノード、及びアクセスノードを備える。各可用性コンテナは通常、可用性コンテナの境界線をまたがる相関障害イベントを防止するように設定されるため、所定のファイルストアに割り当てられた格納サービスノードの集合は一般に、異なる可用性コンテナにわたって分散され得る。一部のファイルストアは、他のファイルストアよりも低い可用性または耐久性要件を有し、そのため、少なくともいくつかの実施形態において、単一可用性コンテナ内で実施され得ることに留意されたい。一実施形態において、ファイル格納サービスが構築されると、いくつかの可用性コンテナ２１２のそれぞれにおける３つのサブシステムのそれぞれに関して、ノードのプールが確立され得る。当該ノードプールから必要に応じて特定のノードが、所定のファイルストアに割り当てられ得る。別の実施形態において、事前設定された格納サービスノードプールを確立する代わりに、必要に応じて新たなノードがインスタンス化され得る。

所定のファイルストアまたはファイルシステムのためにファイル格納を集合的に実行するＡＮ、ＭＮ、及びＳＮの集まりは、そのファイルストアの「ノード集合」２５０と称され得る。図２に示される実施形態において、格納サービスノードはマルチテナントであるため、サブシステムのうちのいずれかの所定のノードは、いくつかの異なるクライアント及び／またはいくつかの異なる顧客からの要求を処理する責任を担い得る。様々な実施形態において、所定の顧客（例えば自身の請求アカウントが格納サービスにおいて開設されている事業主体または個人）は、描かれた実施形態におけるいくつかの異なるファイルストアを立ち上げ、しかも多数の異なるクライアントデバイス（プログラム的インターフェイスが呼び出され得るコンピューティングデバイス）が、単一ファイルストアに対しファイルサービス要求を出すために、所定の顧客により、または所定の顧客のために使用され得ることに留意されたい。少なくともいくつかの実施形態において、複数のユーザアカウント（例えば顧客企業組織の数従業員それぞれの１つまたは複数のユーザアカウント）は、単一請求アカウントの管轄下で開設され、それぞれのユーザアカウントは、様々なクライアントデバイスからファイル格納要求を送り得る。

顧客Ｃ１のファイルストアＦＳ１に使用される図２のノード集合２５０Ａは、２つの可用性コンテナ２１２Ａ、２１２Ｂに分配されたＳＮ１３２Ａ、１３２Ｂ、１３２Ｋと、ＭＮ１２２Ａ、１２２Ｂ、１２２Ｆと、ＡＮ１１２Ａ、１１２Ｂ、１１２Ｈとを備える。別の顧客Ｃ２のファイルストアＦＳ２に使用されるノード集合２５０Ｂは、３つの可用性コンテナ２１２Ａ、２１２Ｂ、２１２Ｃ内のノード、ＳＮ１３２Ｂ、１３２Ｋ、１３２Ｌ、１３２Ｐと、ＭＮ１２２Ｂ、１２２Ｆ、１２２Ｇ、１２２Ｒと、ＡＮ１１２Ｂ、１１２Ｍとを備える。顧客Ｃ１のファイルストアＦＳ３に使用されるノード集合２５０Ｃは、可用性コンテナ２１２Ｃのノードのみ、ＳＮ１３２Ｐ、１３２Ｑと、ＭＮ１２２Ｒ、１２２Ｓと、ＡＮ１１２Ｍ、１１２Ｎとを使用する。所定のファイルストアに使用する特定ノードは、例えば格納サービスの配置コンポーネントにより、様々な要素に基づいてオンデマンドで選択可能であり、そしてノード集合は、変化する格納領域ニーズ、パフォーマンスニーズ、障害等に応じて、時間と共に変化し得る。少なくともいくつかの実施形態において、単一格納ノードにおける所定の格納デバイスは、異なるクライアントに属するデータ及び／またはメタデータを格納し得る。少なくともいくつかの実施形態において、単一エクステントは、複数のクライアントまたは顧客のデータ及び／またはメタデータを含み得る。

いくつかの実施形態において、少なくともＳＮに関して、所定のファイルストアのいくつかの異なる範囲に沿って、冗長性または複製が実施され得る。所定ファイル内のデータ量が増大すると、例えば、ファイルの様々な論理ブロックは一般に、異なる論理エクステントにマッピングされ得る。このように、論理ブロックレベルでファイルストライピングが実施され、これにより、特定パターンのＩ／Ｏ要求に対するパフォーマンスの向上が促進され、また大きなファイルに使用されている格納ノードまたはデバイスのうちの１つが障害を起こした場合に、当該ファイルの復元にかかる時間が削減され得る。いくつかの実施態様において、ファイルのメタデータも、複数のメタデータ論理エクステントにわたりストライピングされ、複数のＭＮにより管理され得る。所望するデータ耐久度を達成するために、各論理エクステント（データ用、メタデータ用に拘わらず）が順番に、例えば消失訂正符号または完全複製を使用して、異なる可用性コンテナ２１２における複数のＳＮにわたって複製され得る。前述のように、少なくとも一実施形態において、低レベル可用性コンテナにわたる複製が、例えば異なるレプリカに対し同一データセンタ内の異なるラックを選択することで、実施され得る。ＡＮ及びＭＮはまた、いくつかの実施形態において、冗長グループに編制され、そのため、あるＡＮまたはＭＮが障害を起こしたとしても、その作業負荷はその冗長グループの別のメンバーにより素早く吸収され得る。

いくつかの実施形態において、プロバイダネットワーク２０２は、様々な顧客のために「隔離仮想ネットワーク」（ＩＶＮ）の確立を支援し得る。所定の顧客のために構築されたＩＶＮ（いくつかの環境において仮想プライベートクラウドまたはＶＰＣとも称され得る）は、プロバイダネットワークの論理的隔離区画内のコンピューティングリソース及び／または他のリソースの集まりを備え得る。これにより、ネットワーク設定に関する実質的な制御が顧客に与えられる。いくつかの実施形態において、例えば、顧客は、ＩＶＮリソースに使用するＩＰ（インターネットプロトコル）アドレス範囲を選択し、ＩＶＮ内のサブネットの作成、及びＩＶＮのための経路テーブル、ゲートウェイ等の設定を管理し得る。いくつかの実施形態において、ＩＶＮ内のデバイスのうちの少なくともいくつかに関して、ネットワークアドレスは、少なくともデフォルトでＩＶＮの外部には見えないようにされ得る。ＩＶＮと顧客の外部ネットワーク（例えば顧客のデータセンタまたはオフィス構内におけるデバイス）との間の接続を可能にするために、プライベートアドレスと共に使用するように構成された仮想インターフェイス（そのためプライベート仮想インターフェイスと称され得る）と、仮想プライベートゲートウェイが設置され得る。いくつかの実施形態において、１つまたは複数のＶＰＮ（仮想プライベートネットワーク）が、顧客のＩＶＮと外部ネットワーク（顧客のオフィスネットワークまたは顧客のデータセンタ等）との間に構成され得る。少なくともいくつかの実施形態において、このようなＶＰＮは、ＩＰＳｅｃ（インターネットプロトコルセキュリティ）、ＳＳＬ／ＴＬＳ（セキュアソケット層／トランスポート層セキュリティ）、ＤＴＬＳ（データグラムトランスポート層セキュリティ）等のセキュアネットワークプロトコルを使用し得る。

いくつかの実施形態において、セキュリティまたは他の理由で、分散格納サービスにより管理される所定のファイルストアへのアクセスは、１つまたは複数のＩＶＮ内のクライアントデバイスの特定集合に限定され得る。図３は、少なくともいくつかの実施形態による、隔離仮想ネットワーク３０２に対応付けられたネットワークアドレスが、格納サービスのアクセスサブシステムノードに割り当てられる構成を例示する。このようなアドレス割り当ての結果、自身のネットワークアドレスもＩＶＮ内にあるクライアントのみが、ＡＮ１１２を介してファイルストアにアクセス可能になり得る。示されるように、図３のプロバイダネットワーク２０２は、ＳＮ１３２Ａ〜１３２Ｆと、ＭＮ１２２Ａ〜１２２Ｆと、ＡＮ１１２Ａ〜１１２Ｆとを備える。２つのＩＶＮ３０２Ａと３０２Ｂが、顧客ＡとＢそれぞれのために、プロバイダネットワーク２０２内に構築されている。各ＩＶＮは、仮想コンピューティングサービス３０２のいくつかの演算インスタンス（ＣＩ）を含む。ＣＩにおいて、ファイル格納サービスを要するアプリケーションが稼働し得る。ＩＶＮ３０２Ａに示されるＣＩ（例えばＣＩ３８０Ａ、３８０Ｂ）及びＩＶＮ３０２Ｂに示されるＣＩ（ＣＩ３８０Ｋ、３８０Ｌ）に加えて、他のＣＩ（例えば３８０Ｐ、３８０Ｑ）も、描かれた実施形態において、ＩＶＮの外部のインスタンスホスト上で稼働し得る。従って、ファイル格納サービスの全てのクライアントがＩＶＮ３０２に必ずしも属する必要はない。

ＩＶＮ３０２Ａ内のＣＩからファイル格納サービスへのアクセスを可能にするために、ＡＮ１１２Ａ、１１２Ｄに対し、ＩＶＮ３０２Ａに対応付けられたプライベートＩＰ（インターネットプロトコル）アドレス３５０Ａが割り当てられている。その結果、ＩＶＮ３０２ＡのクライアントＣＩ３８０Ａ、３８０Ｂは、アドレス３５０Ａを使用してファイル格納サービスインターフェイスを呼び出し、ファイル格納サービスとのインタラクション時に、ＩＶＮに既に実装されている様々なネットワーク分離及びセキュリティ機能に依存することが可能になり得る。同様に、ＡＮ１１２Ｄ、１１２Ｅに対し、ＩＶＭ３０２Ｂのプライベートネットワークアドレスが割り当てられ、これにより、ＩＶＮ３０２ＢのクライアントＣＩ３８０Ｋ、３８０Ｌから安全なアクセスが可能になる。少なくともいくつかの実施形態において、所定のＡＮ（１１２Ｄ等）に対し複数のネットワークアドレスが割り当てられ、これにより、単一ＡＮリソースが複数のＩＶＮにより共有されることが可能になることに留意されたい。別の実施形態において、各ＡＮは、単一のＩＶＮのネットワークアドレスに限られ得る。プライベートアドレスに加えて、いくつかの実施形態において、パブリックネットワークアドレス（例えば公衆インターネットからアクセス可能なＩＰアドレス）も、ＡＮ１１２Ｃ等の少なくともいくつかのＡＮに使用され、これにより、ＩＶＮの一部ではない３８０Ｐまたは３８０Ｑ等のＣＩからアクセスが可能になる。一実施形態において、プロバイダネットワーク２０２の外部に配置されたクライアントも、パブリックＩＰアドレスを使用して格納サービスにアクセスすることが可能になり得る。いくつかの実施形態において、単一の（プライベートまたはパブリック）ネットワークアドレスは、複数のＡＮ１１２に割り当てられ得る。その結果、例えば、受信作業要求は複数のＡＮにわたって均衡化され、クライアントに影響を与えることなくＡＮフェイルオーバーが実施され得る（例えば、特定のＡＮに障害が起こった後でも、同一のネットワークアドレスが割り当てられた残りのＡＮがクライアント要求に応答し続け得るため、クライアントは同一アドレスに対しファイル格納要求を送信し続けられる）。

論理ブロック、ページ、及びエクステント
図４は、少なくともいくつかの実施形態による、ファイル格納サービスオブジェクトと、論理ブロックと、１つまたは複数のエクステントにおける物理ページとの間のマッピングを例示する。ファイルＦ１に関して、３つの論理ブロックＬＢ４０２Ａ、４０２Ｂ、４０２Ｃが構成されている。ファイルまたはメタデータ構造等、所定オブジェクトの異なる論理ブロックのコンテンツは一般に、別個の格納場所に格納され得るため、論理ブロックは本明細書においてストライプとも称され得る。いくつかの実施形態において、ファイルＦ１のストライプＡ、Ｂ、Ｃ等、ストライプの物理的分離が実施される。例えば、所定オブジェクトの２つのストライプは、同一の物理格納デバイスに格納され得ない。別の実施形態において、ストライプの物理的分離は、系統だった施行なしでも、例えば多数の物理デバイスにわたるストライプのランダム分散または略ランダム分散の使用により、高い確率で起こり得る。少なくともいくつかの実施形態において、所定のファイルまたはメタデータ構造内において、論理ブロックサイズは異なり得る。別の実施形態において、少なくともいくつかの格納サービスオブジェクトの全ての論理ブロックは、同一サイズであり得る。描かれた実施形態において、各論理ブロック４０２のコンテンツは、所定のデータエクステント４３４の１つまたは複数の物理ページ（ＰＰ）４１２に格納され得る。従って、例えばＬＢ４０２のコンテンツは、格納ノード１３２Ｄのデータエクステント４３４ＣにおけるＰＰ４１２Ｊ、４１２Ｋ、４１２Ｌに書き込まれている。ＬＢ４０３のコンテンツは、格納ノード１３２Ｂのデータエクステント４３４Ａ内のＰＰ４１２Ｂに格納され、ＬＢ４０４のコンテンツは、格納ノード１３２Ｃにおける格納エクステント４３４ＢのＰＰ４１２Ｆに格納される。ブロックとページ間のマッピングに関する論述を簡潔にするために、図４においてエクステントレプリカは図示されない。少なくとも描かれた実施形態において、エクステントの複製に使用される技術は、ブロックをページにマッピングするために使用される技術とは無関係であり得る。

少なくともいくつかの実施形態において、さらに詳しく後述されるように、物理格納に動的オンデマンド割り当てが使用され得る。これに従って、所定の書き込み要求を受信した時には、書き込み要求の書き込みペイロードを格納するのに実際に必要となるページの集合のみが実際に割り当てられ得る。特定のＬＢの論理ブロックサイズが８メガバイトであり、ＬＢがマッピングされたエクステントに６４キロバイトの固定ページサイズが使用され、そしてＬＢに対する第１書き込みが５６キロバイトの書き込みペイロードを含むという、例示的シナリオを検討する。このようなシナリオにおいて、オンデマンド割り当てが使用される実施形態においては、格納領域の１ページ（６４キロバイト）のみが要求に応じて割り当てられ得る。別の実施形態においては、全ＬＢの物理格納が、書き込みペイロードサイズに関係なく、ＬＢに対する第１書き込み要求に応じて確保され得る。

クライアントが特定のファイルに対し初めて書き込みを行う時、選択されたメタデータサブシステムノードは、１つまたは複数の論理ブロック４０２に関するメタデータ４７５を生成し得る（例えばいくつかの事例において、論理ブロックサイズに対する書き込みペイロードのサイズにより、複数の論理ブロックが必要となり得る）。描かれた実施形態において、当メタデータ４７５自体は、メタデータエクステント４６４のＰＰ４１２Ｑ等の１つまたは複数の物理ページに格納され得る。少なくともいくつかの実施形態において、メタデータ構造に使用されているブロックサイズ及び／またはページサイズは、対応データに使用されているものとは異なり得る。少なくとも一実施形態において、メタデータエクステントは、データに使用される格納デバイス（例えば回転ディスク）とは異なるクラスまたは種類の格納デバイス（例えばＳＳＤ）を使用して格納され得る。いくつかの実施態様において、メタデータの少なくとも一部と同一ファイルストアオブジェクトのメタデータの少なくとも一部は、同じエクステントに格納され得る。

いくつかの実施形態において、前述のように、データエクステント４３４及び／またはメタデータエクステント４６４のコンテンツは、例えばそれぞれのデータ耐久性要件を満たすために、複製され得る。このような実施形態において、さらに詳しく後述されるように、論理エクステントの特定のレプリカは、マスタレプリカとして選ばれ、そしてエクステントに対する更新は、マスタレプリカにより（またはマスタレプリカが属する格納ノードにより）、例えば対応更新要求が成功したことを示す前にマスタから要求数のレプリカに対し更新を伝播することで、開始及び／または調整され得る。

エクステントの任意の所定レプリカが格納される格納デバイスにおいて所定の論理ブロックのコンテンツが書き込まれる順序は異なり得る。すなわち、特定の１メガバイトの論理ブロックに対応する２つの３２キロバイトの物理ページＰ１及びＰ２が、ディスクまたはＳＳＤ上に「Ｐ１の後にＰ２が続く」という順序で配置されたとしても、これは必ずしもＰ１内のデータがＰ２内のデータよりも論理ブロック内において小さい開始オフセットを有することを意味するわけではあり得ない。いくつかの実施形態において、例えば向上した順次読み出しまたは書き込みパフォーマンスを促進するために、ページは、第１書き込みが行われた後に移動され得る（すなわちその格納デバイス内で再配置され得る）。所定のエクステントまたはエクステントレプリカ内に、いくつかの異なるファイルに対応付けられた物理ページが格納され得る。例えば、メタデータエクステント６３４において、Ｆ１以外の１つまたは複数のファイルのブロック対ページマップ（または他のメタデータ）が、ＰＰ４１２Ｐ、４１２Ｒ、４１２Ｓに格納され得る。同様に、ページ４１２Ａ、４１２Ｃ、４１２Ｄ、４１２Ｅ、４１２Ｇ、４１２Ｈ、４１２Ｍは全て、Ｆ１以外のファイルのコンテンツを格納し得る。いくつかの実施形態において、同一ファイルの任意の２つの論理ブロックが同じエクステントに（例えば同じエクステントレプリカグループに）マッピングされる確率が非常に低くなり得るのに十分な程の多数のエクステントが確立され得る。このようなシナリオにおいて、Ｉ／Ｏ要求は（ほとんどの事例において）異なる格納ノード及び異なる格納デバイスを対象とし得るため、同一ファイルの異なる論理ブロックに対する同時Ｉ／Ｏ要求に、並行して応答することが可能であり得る。少なくとも一実施形態において、格納システムは一般に、例えば特定のブロックに第１書き込みが行われる時に利用可能な空き格納領域量等の要素に基づいて特定のブロックに使用するエクステントを選択することにより、明らかにランダムまたは略ランダムに論理ブロックを利用可能エクステント間に分配する傾向があり得る。

図５は、少なくともいくつかの実施形態による、データエクステント及びメタデータエクステントのレプリカグループ５１０の構成を例示する。データエクステントＤ１、Ｄ２の２つのレプリカグループ５１０Ａ、５１０Ｂが示され、メタデータエクステントＭ１、Ｍ２の２つのレプリカグループ５１０Ｃ、５１０Ｄが示される。一般に、同一論理エクステントの２つの物理レプリカが、同じ格納デバイス上または同じ格納ノードにおける異なる格納デバイス上に格納される場合もあり得るが、例示される各レプリカグループは、格納サブシステムのそれぞれの格納ノード１３２におけるそれぞれの格納デバイス５３２に、２つ以上のレプリカを含み得る。

各レプリカグループ５１０は、１つのマスタレプリカと、１つまたは複数の非マスタレプリカとを含むように示される。マスタレプリカは、例えば複製ステートマシン及び／またはコンセンサスベース更新プロトコルを使用して、レプリカグループのメンバーに対する書き込みを調整する責任を担い得る。いくつかの実施形態において、複製ステートマシン及び／またはコンセンサスベースプロトコルは、読み出しにも同様に使用され得る。複製グループにおけるレプリカの総数は、レプリカに格納されているファイルデータ及び／またはメタデータに対する耐久性要件に応じて、変わり得る。図５において、レプリカ５６４Ａはグループ５１０Ａのマスタレプリカであり、レプリカ５６５Ｂはグループ５１０Ｂのマスタレプリカであり、レプリカ５７５Ｂはレプリカグループ５１０Ｃのマスタレプリカであり、レプリカ５７６Ｂはレプリカグループ５１０Ｄのマスタレプリカである。レプリカグループ５１０Ａ、５１０Ｃは、２つの非マスタレプリカをそれぞれ含む（グループ５１０Ａにレプリカ５６４Ｂ、５６４Ｃ、グループ５１０Ｂにレプリカ５７５Ａ、５７５Ｃ）。消失訂正符号技術、完全複製、または完全複製と消失訂正符号複製の組み合わせ等、様々な実施形態において、異なる種類の複製技術が使用され得る。いくつかの実施形態において、異なる複製技術が、異なるファイルストアに使用され得る。

少なくともいくつかの実施形態において、１つまたは複数の種類のＳＳＤ、及び／または回転磁気ディスクに基づいた１つまたは複数の種類の個別デバイスまたはアレイデバイス等、様々な異なる格納デバイスが、エクステントレプリカを格納するために利用可能であり得る。いくつかの実施形態において、所定の格納ノード１３２はいくつかの異なる種類の格納デバイスを備え、一方他の実施形態において、所定の格納ノードは単一の種類の格納デバイスのみが利用可能であり得る。描かれた実施形態において、格納ノード１３２Ａ、１３２Ｂ、１３２Ｃはそれぞれ、ＳＳＤデバイス（３つのノードにそれぞれデバイス５３２Ｂ、５３２Ｌ、５３２Ｔ）、並びに回転ディスクベースのデバイス（それぞれ５３２Ａ、５３２Ｋ、５３２Ｓ）を有する。いくつかの実施態様において、データエクステントレプリカの格納、メタデータエクステントレプリカの格納、または格納領域が利用可能であれば両種類のエクステントの格納のために、１つの特定の格納デバイス技術が選ばれ得る。一実施態様において、例えば、メタデータエクステントは、可能であればＳＳＤ上に格納され、一方データエクステントは、より安価な回転ディスクに格納され得る。いくつかの実施形態において、データエクステント及び／またはメタデータエクステント、あるいはそれらの一部は、例えば使用レベルに基づいて、ある種類の格納デバイスから別の種類の格納デバイスへ移行され得る。

メタデータキャッシング
図６は、少なくともいくつかの実施形態による、ファイル格納サービスのアクセスサブシステムノードにおけるメタデータのキャッシングに伴うインタラクション例を示す。先に述べたように、いくつかの実施形態において、外部負荷分散装置は、クライアントの作業負荷を利用可能なアクセスサブシステムノードに分配するように構成され得る。図６に描かれた実施形態において、負荷分散装置６４６において、クライアント１８０からのサービス要求６４４Ａ（ファイルに対する書き込みまたは読み出し等）が受信される。負荷分散装置６４６は、対応サービス要求６４４Ｂを、元のサービス要求６４４Ａに使用したネットワーク接続とは異なるネットワーク接続を介して、選択されたアクセスノード１１２へ転送する。

アクセスノード１１２は、様々なファイルストアオブジェクトに関するメタデータオブジェクトのキャッシュ６０４を保持し得る。転送されたサービス要求６４４Ｂに対応するページの適切な集合を格納する格納サブシステムノード１３２を特定するのに十分なメタデータがキャッシュ６０４内に偶然ある場合、アクセスノードは、格納ノードに対し読み出し／書き込み要求を発し得る。しかしながら、メタデータがキャッシュされていない場合、アクセスノード１１２は、矢印６９３に示されるように、選択されたメタデータサブシステムノード１２２に対しメタデータ要求６５０を送り得る。先に述べたように、いくつかの実施形態において、メタデータコンテンツは、格納サブシステムノードに実際に記憶され得る。メタデータノード１２２（例えばメタデータ管理コードを実行するプロセスを含み得るメタデータノード１２２）自体は、別のキャッシュ層を含むメタデータのインメモリ集合６１２を保持し得る。アクセスノードにより要求されたメタデータがインメモリ集合６１２内にない場合、メタデータノードは、矢印６９４に示されるように、１つまたは複数の格納ノード１３２Ａからメタデータを含むページ６５４を取得し、自身のインメモリ集合６１２に当該メタデータを格納し得る。いくつかの事例において、クライアントからの要求６４４Ａは、新たなメタデータを生成することを要求し得る（例えば要求がファイルに対する第１書き込みである場合、メタデータノードは、ファイルの第１論理ブロックに対するメタデータエントリを作成し得る）。この場合、メタデータノードは、描かれた実施形態において、要求６５０に応答する前に、確実に新たなメタデータが格納ノード１３２に無事格納されるようにし得る。

クライアントの要求に応答するために必要とされる、格納ノード１３２Ａから取得したメタデータの少なくとも一部（要求関連メタデータ６５２と称される）は、矢印６９５に示されるように、アクセスノード１１２に提供され得る。アクセスノードはメタデータを読み出し、メタデータをキャッシュ６０４に格納し、矢印６９６に示されるように、メタデータにより特定された適切な格納ノード（複数可）１３２に対し、読み出しまたは書き込み要求（複数可）６５５を送り得る。図６に図示されていないが、格納ノード（複数可）１３２Ｂは、読み出し／書き込み要求（複数可）に対する応答を提供し、そしてアクセスノードは、いくつかの実施形態において、要求されたサービス動作が成功したか否かを示すようクライアント１８０に応答し得る。アクセスノード１１２は、メタデータサブシステムからのメタデータを再度取得する必要なく、キャッシュされたメタデータを使用して、少なくともいくつかの後続クライアント要求に応答可能であり得る。

描かれた実施形態において、明示的キャッシュ無効メッセージを使用する代わりに、アクセスノードにおいてメタデータキャッシュエントリの潜在的失効を管理するために、タイムアウトベース技術が使用され得る。従って、アクセスノード１１２は、キャッシングタイムアウト設定（複数可）６０８を使用して、キャッシュ６０４から任意の所定メタデータ要素を排除する時を決定し得る。いくつかの実施態様において、所定のメタデータエントリは、そのタイムアウト時間６０８が経過した後、別のクライアント要求に必要とされるまで再キャッシュを試みることなく、キャッシュ６０４から単純に削除され得る。別の実施態様において、またはいくつかの選択された種類のメタデータエントリに関して、アクセスノード１１２は、メタデータエントリのキャッシュタイムアウト時間が経過した時にメタデータノード１２２からそのメタデータエントリを再度要求し得る、あるいはメタデータエントリが変わらず有効であるか否かを調べ得る。後者のシナリオにおいて、エントリが再有効化、またはリフレッシュされる度に、タイムアウト時間は元の値にリセットされ得る。描かれた実施形態において、メタデータの所定の論理ブロックに関して別の種類のタイムアウト設定が、メタデータノード１２２にて使用され得る。メタデータノード１２２が最初にあるファイルストアオブジェクトのメタデータを生成し、メタデータ構造の所定の論理ブロックにメタデータを格納すると、メタデータ論理ブロックが再割り当て可能となるまでに経過しなくてはならない最短時間を示す、メタデータブロック再割り当て不適格性タイムアウト時間が開始され得る。（このようなメタデータ再割り当ては、例えばメタデータがブロックに格納されていたオブジェクトが削除された場合に、最終的に起こり得る。）ブロック再割り当て不適格性タイムアウト設定（複数可）６１４は通常、該当するブロックのメタデータのキャッシュタイムアウト設定６０８よりも長い時間が設定され得る。例えば、一実施態様において、ブロック再割り当てタイムアウト値は２週間であり、一方キャッシュタイムアウト設定は１日であり得る。このようなシナリオにおいて、アクセスノード１１２は、毎日１度メタデータの所定のブロックの有効性を調べ直し、同時にメタデータノード１２２は、確実にそのブロックが、最初に割り当てられた時から２週間が経過する前に、ある他の目的のために再利用されないようにし得る。

いくつかの実施形態において、タイムアウトベース機構を使用する代わりに、アクセスノードにおいてキャッシュされるメタデータエントリに、明示的リースまたはロックが使用され得る。少なくとも一実施形態において、例えばメタデータのある要素がもう有効ではない場合に、メタデータノード１２２は無効メッセージを送信し得る、明示的キャッシュ無効機構が使用され得る。一実施形態において、メタデータサブシステムは、メタデータの変化に応じて、メタデータのブロックを「無効」または「アクセス不可」と示し得る。アクセスノードがデータブロックにアクセスするために無効キャッシュメタデータの使用を試みると、メタデータサブシステムまたは格納サブシステムにより、メタデータは無効であることを示すエラーメッセージがアクセスノードに対し返され得る。従って、このようなエラーメッセージの結果、キャッシュメタデータは非明示的に無効化され得る。アクセスノードにおいてキャッシュされるメタデータの異なる実施形態において、タイムアウトベース、ロック／リースベース、非明示的及び明示的無効ベース戦略の様々な組み合わせが使用され得る。

６９３、６９４、６９６と表示された矢印により示されるインタラクション等、図６に描かれたインタラクションのうちのいくつかにおいて、格納サービスのいくつかのコンポーネントは、他のコンポーネントのクライアントとして機能し得る。例えば、アクセスノード１１２は、メタデータノードのクライアントとして機能するメタデータノードに対し、内部要求（すなわち格納サービス内で生成され、格納サービスの顧客は直接アクセス不可能なネットワーク経路を使用する要求）を送信し得る（矢印６９３）。同様に、メタデータノードとアクセスノードの両方は、格納ノードのクライアントとして機能する格納ノード１３２に対し内部要求を送信し得る。いくつかの実施形態において、様々なサブシステムは、このようなインタラクションを可能にするために、格納サービスの他のコンポーネントにより呼び出し可能な内部ＡＰＩを実行し得る。格納ノード１３２は、例えば、特定の格納サービスＡＰＩがアクセスノード１１２から呼び出されようと、メタデータノード１２２から呼び出されようと、同じように応答し得る。従って、少なくともいくつかの実施形態において、格納サービスノードは、格納サービスノードが協力的に受信する内部要求の発信元に対し、依存し得ない。

ファイルストアポリシー
いくつかの実施形態において、特定のファイルストアに関して、ファイル格納サービスの動作の様々な態様を制御する相当な柔軟性が、クライアントに与えられ得る。例えば、特定のファイルストアに対する耐久性、パフォーマンス、可用性、または他の要件を、クライアントが設定または変更することを可能にするために、１つまたは複数の管理ＡＰＩが実施され得る。特定のファイルストアに対する該当要件は、同一クライアントまたは他のクライアントのために作成される他のファイルストアの該当要件とは異なり得る。図７は、少なくともいくつかの実施形態による、ファイルストアに対する、データ耐久性、パフォーマンス、及び論理対物理データマッピングに関するポリシーの異なる組み合わせの使用例を示す。

列７０４、７１４に示されるように、ＦＳ１等の所定のファイルストアのデータ及びメタデータそれぞれに対する耐久性ポリシーは異なり、ＦＳ１及びＦＳ２等の異なるファイルストアにおいて使用される耐久性ポリシーは、データ、メタデータ、またはその両方において異なり得る。ＦＳ１に関して、メタデータに十重完全複製が使用され（メタデータの各ページの１０個の完全コピーが保持される）、一方データ耐久性に１２／６消失訂正符号が使用される（各データページの１２個の消失訂正符号コピーが格納され、そのうち６個のコピーがページのコンテンツを復元する必要がある）。ファイルストアＦＳ１、ＦＳ２のメタデータ及びデータに対するパフォーマンス目標／要件は、列７０６、７１６にそれぞれ示される。パフォーマンス目標は、例えば待機時間または応答時間の単位（列７０６、７１６において表示「ｒｅｓｐｔｉｍｅ」で示される）に対する処理量の単位（表示「ｔｐｕｔ」で示される）といった様々な単位で表現され、そしていくつかの事例において、書き込み（列７０６、７１６において表示Ｗで示される）に対する要件の集合とは異なる要件の集合が、読み出し（表示Ｒで示される）に対し指定され得る。例えば、所定のファイルストアのメタデータまたはデータに使用されるべき格納デバイスの種類を選択するために、パフォーマンス目標が使用され得る。

描かれた実施形態において、それぞれのファイルストアの格納オブジェクトに対し格納領域を割り当てるために、異なる手法が使用され得る。例えば、列７０８に示されるように、５１２キロバイトの固定論理ブロックサイズと動的ページ割り当てのポリシーがＦＳ１メタデータに使用され、一方ＦＳ２メタデータに対し、１メガバイトの論理ブロックの物理格納領域が静的に割り当てられ得る。列７１８に示されるように、ＦＳ１データに対し異なる論理ブロックサイズが使用され得る。所定ファイルの最初のいくつかの論理ブロックは、１キロバイト、１キロバイト、２キロバイト、２キロバイト、等に設定され、論理ブロックサイズは所定のファイルが大きくなるにつれて次第に大きくなる。対照的に、ＦＳ２データに対し、固定サイズ４メガバイトの論理ブロックが使用され得る。メタデータに使用される物理ページサイズは、ＦＳ１に対し８キロバイト、ＦＳ２に対し１６キロバイトというように設定され得る（列７１０）。データに関して、列７２０に示されるように、ＦＳ１に対し、ページサイズは論理ブロックと同じに設定され、一方ＦＳ２に対し、ページサイズは３２キロバイトに設定され得る。図６を参照して前述されたメタデータキャッシュタイムアウト及びブロック再割り当て不適格性タイムアウトを含む、ＦＳ１及びＦＳ２に対するそれぞれのメタデータキャッシュ関連設定が、列７１２に示される。いくつかの実施形態において、例えばファイル格納サービスの実施複雑度を低減するために、耐久性ポリシー、ブロック及びページサイズ決定ポリシー等に関するオプションの離散集合のみが対応され得る。いくつかの実施形態において、可用性関連要件、稼働時間要件、ファイルストア領域限度等、他の種類のポリシーも、異なるファイルストアに対し異なるように設定され得る。少なくとも一実施形態において、クライアントは、ファイルストアごとに、複数の価格設定ポリシーの中から選ぶことも可能であり得る。例えば、一部のクライアントは格納領域使用ベース価格設定ポリシーを選択し、一方他のクライアントはファイルシステムＡＰＩカウントベース価格設定ポリシーを選択し得る。

拡張縮小可能ファイル格納サービスを実施する方法
図８ａは、少なくともいくつかの実施形態による、拡張縮小可能な分散ファイルシステム格納サービスを実施するために実行され得る構成及び管理関連動作の態様を例示するフロー図である。構成要素８０１に示されるように、例えばサービス初期化手続き中に、分散ファイル格納サービスのＮ個の異なる格納サブシステムノードにおいて、データ及び／またはメタデータのために、Ｍ個の空エクステントの初期集合が確立され得る。いくつかの実施形態において、プロバイダネットワークにて確立された仮想コンピューティングサービスの演算インスタンス上で稼働するクライアントアプリケーションのために、ファイル格納動作を実施するように、格納サービスは設定され得る。様々な実施形態において、例えばＭはＮよりも大きくあり得るように、各格納ノードは複数のエクステントを備え得る。データ耐久性のためにエクステントコンテンツが複製される実施形態において、Ｍ個の空エクステントそれぞれは、論理エクステントのコンテンツのそれぞれのレプリカを格納可能であり得る。各格納ノードは、例えば複数の回転ディスクベースデバイス及び／またはソリッドステートストアデバイスを含む１つまたは複数の格納デバイスを備え得る。所定のエクステントは、いくつかの実施形態において単一格納デバイス内に組み込まれ、他の実施形態において複数の格納デバイスにわたって分散され得る。一実施形態において、例えば格納サービスに対応付けられた設定可能パラメータに基づいて、全てのエクステントは同じサイズであり得る。別の実施形態において、異なるエクステントは異なるサイズを有し、及び／またはエクステントのサイズは時間と共に変化し得る。格納サービスの所定のインスタンス化におけるエクステントの総数は、時間と共に変わり得る。例えば、メタデータ及びデータのサイズが大きくなると、より多くの格納デバイス及び／またはより多くのエクステントが展開され得る。いくつかの実施形態において、エクステントは、格納サービスのデータ及びメタデータに関する復元単位を表し得る。例えば、消失訂正符号、完全複製、または複製技術のある組み合わせを使用して、耐久性ポリシーまたは設定に基づいて、各エクステントは複製され得る。各エクステントレプリカグループ（すなわち同一論理データエクステントまたは同一論理メタデータエクステントのレプリカグループ）は、マスタレプリカに指定された少なくとも１つのレプリカを含み得る。マスタレプリカの格納ノード（論理エクステントに関してマスタノードまたはリーダノードとも称され得る）は、グループメンバー間の更新を調整する責任を担う。いくつかの実施形態において、マスタ選択及び／またはレプリカグループのメンバーに関する決定は、ファイルストアの第１オブジェクトが書き込まれるまで先送りされ得る。少なくともいくつかの実施態様において、エクステントはマルチテナントであり得る。例えば、各エクステントは、多数の異なるクライアントまたは顧客のデータまたはメタデータを格納し得る。

描かれた実施形態において、少なくとも特定のファイルストアＦＳ１にアクセスできるように、複数のアクセスサブシステムノードが最初に確立され得る（構成要素８０４）。例えば、ファイルストアクライアントが隔離仮想ネットワーク（ＩＶＮ）の演算インスタンスを備える実施形態において、ＩＶＮ内からのみアクセス可能なプライベートＩＰアドレスは、Ｐ個のアクセスサブシステムノードに割り当てられ得る。いくつかの実施形態において、パブリックＩＰアドレスが、同様にまたは代わりに、アクセスサブシステムノードの一部または全てに割り当てられ得る。いくつかの実施形態において、部分的に事前設定されたアクセスサブシステムノードのプールが構築され、当該プールから特殊アクセスノードが特定のファイルストアに割り当てられ、他の実施形態において、アクセスノードはオンデマンドでインスタンス化され得る。少なくとも一実施形態において、所定のネットワークアドレスは、複数のアクセスサブシステムノードに割り当てられ得る。

いくつかの実施形態において、ファイルストア作成の際、Ｑ個のメタデータノードの集合が、ファイルストアＦＳ１に割り当てられ得る。別の実施形態において、例えばファイルまたはディレクトリ等のＦＳ１のオブジェクトに対する第１書き込み要求を受信した時に（図８ｂを参照して後述）、オンデマンドで、メタデータノード（同様に事前設定プールから選択され得る、または動的にインスタンス化され得る）は、ＦＳ１に割り当てられ得る。描かれた実施形態において、ファイル格納サービスの管理コンポーネントは、アクセスサブシステム、メタデータサブシステム、及び格納サブシステムの様々なノードのパフォーマンス及び／または健全ステータスを監視し得る（構成要素８０７）。描かれた実施形態において、任意の所定クライアントのために実行されたファイルストア完了または成功動作の記録が格納され、このような記録は、後にクライアントに対し利用ベース請求額を生成するために使用され得る。観測されたパフォーマンスメトリクスの分析及び／または健全ステータスの変化に応じて、サブシステムのうちのいずれかに対し、他の層の保有ノード数に作用することなく、かつ受信ファイル格納要求のストリームに影響を与えることなく、動的にノードが追加または削除され得る（構成要素８１０）。例えば、アクセスサブシステムにおける潜在的パフォーマンスボトルネックの検出、または障害が起こった、もしくは応答のないアクセスサブシステムノードの検出に応じて、より多くのアクセスサブシステムノードが、他のサブシステムノードのどちらにも影響を与えることなく、インスタンス化され得る。いくつかの事例において、１つまたは複数のノードにおけるリソース使用（例えばＣＰＵまたは格納領域使用）がある時間を通して閾値未満である場合、このようなノードは削除され、その作業負荷は他のノードに分配され得る。従って、それぞれのサブシステムは、必要に応じて独立して拡張または縮小可能である。

図８ｂは、少なくともいくつかの実施形態による、拡張縮小可能な分散ファイルシステム格納サービスにおいてクライアント要求に応じて実行され得る動作の態様を例示するフロー図である。例えば、ファイルストアＦＳ１のファイルに対する作成（例えば「オープン」ＡＰＩの呼び出し）または第１書き込み要求に応じて、１つまたは複数の選択されたメタデータエクステント及びデータエクステントにおいて格納領域が割り当てられ得る（構成要素８５１）。描かれた実施形態において、メタデータサブシステムは、格納サブシステムノードにメタデータコンテンツを格納し得る。例えば、メタデータ専用の別個の格納層を実施する代わりに、格納サブシステムの格納能力がメタデータに再利用され得る。別の実施形態において、データに使用されるものとは別個の格納サブシステムが、メタデータに使用され得る。所望するデータ耐久性を達成するために複製が使用されている実施形態において、複数のメタデータ及び／またはデータエクステントにおいて、例えば適切なエクステントレプリカグループの全てのメンバーに対し、格納領域が割り当てられ得る。異なる実施形態において、例えば、エクステントの現在の充足度に基づいて、作成されているオブジェクトのパフォーマンス要件に対するエクステントのパフォーマンス特性に基づいて等、様々な要素に基づいて、第１書き込みに応答するために１つまたは複数のページを割り当てるように特定のエクステントが選択され得る。少なくともいくつかの実施形態において、ファイルストアのオブジェクトの現在の「分散」も、エクステントを選択する時に考慮され得る。例えば、格納サブシステムは、同じエクステントまたは同じ格納ノードに所定のファイルストアのデータまたはメタデータの多くのブロックを格納し過ぎることを回避することにより、「ホットスポット」の可能性を低減するように試み得る。

ＦＳ１内のオブジェクトに対し追加書き込みが行われると、例えば適用ストライピングポリシー（すなわち論理ブロック対物理ページマッピングポリシー）に基づいた別の格納サブシステムノードにおいて、追加格納領域がデータ及び／またはメタデータに割り当てられ、そして必要に応じて追加メタデータノードが構成され得る（構成要素８５４）。少なくともいくつかの実施形態において、格納サブシステム、アクセスサブシステム、及びメタデータサブシステムの３つのサブシステムそれぞれのノードは、マルチテナント機能に対応するように構成され得る。例えば、各格納サービスノードは、同時にいくつかの異なるクライアントからの格納要求を処理し得る、または同時にいくつかの異なるクライアントのデータ／メタデータを格納し得る。クライアントは、自身の格納要求に使用されているものと同じリソースが、他のクライアントからの要求にも使用されていることに気づき得ない。いくつかの実施形態において、各格納サービスノードは、例えば、プロバイダネットワークのホストまたはサーバを使用して実行され得る１つまたは複数のプロセスもしくはスレッドを含み得る。

時間と共に、ディレクトリまたはファイル等の所定のファイルストアオブジェクトに対応するメタデータは、最終的にいくつかの異なる格納ノードにおけるいくつかの異なるエクステントにわたって分配され得る。いくつかのファイル格納動作（例えば名前変更動作または削除動作）は、複数のエクステントにおける、または複数の格納ノードにおけるメタデータに対する変更を要求し得る。このような動作に対する要求に応じて、格納サービスは、逐次一貫性を支援または施行する方法で、複数のメタデータページまたは複数のメタデータエクステントにおける変更を含む原子更新動作を実行し得る（構成要素８５７）。異なる実施形態において、多数の異なる種類の一貫性施行技術のうちのいずれかが使用され得る。例えば、分散トランザクション技術、またはオブジェクト名無撞着変更技術等が使用され得るが、どちらもさらに詳しく後述される。

図９は、少なくともいくつかの実施形態による、分散ファイルシステム格納サービスにおいて複製ベース耐久性ポリシーを実施するために実行され得る動作の態様を例示するフロー図である。構成要素９０１に示されるように、所定のファイルストアオブジェクトＦ１のデータ及び／またはメタデータに使用される予定の耐久性関連パラメータの集合のそれぞれのパラメータ値が、例えば当該オブジェクトが作成された時に決定され得る。いくつかの実施形態において、パラメータは、例えばオブジェクトのコンテンツ、またはオブジェクトに関連するメタデータのコンテンツを格納する各ページのレプリカ数、従って各エクステントのレプリカ数といった、レプリカ総数を含み得る。いくつかの実施形態において、複製戦略（例えば、完全複製が使用されるか、消失訂正符号複製が使用されるか、またはこのような技術のある組み合わせが使用される）、及び／または利用可能データセンタリソース間のレプリカの配置も、パラメータとして特定され得る。例えば、格納サービスが複数の可用性コンテナを含むいくつかの実施形態において、少なくとも１つのレプリカが、Ｋ個の可用性コンテナそれぞれの中に配置され得る。それからパラメータに従って、エクステントレプリカの適切な集合が特定され得る（構成要素９０４）。いくつかの実施形態において、様々な候補における利用可能な空き格納領域の量、エクステントまたはそれを含む格納サーバにおける最近の作業負荷レベル、クライアント要求の予想発信元に関する位置関係、前述のように格納領域が割り当てられているファイルストアの「分散」の分析に基づいて、または他のメトリクスに基づいて、特定の物理エクステントは選ばれ得る。レプリカのうちの１つはマスタレプリカとして指定され、その格納ノードは、レプリカグループのメンバーの中のファイルストアオブジェクトに対する書き込み等、様々な動作を調整する責任を担うリーダとして指定され得る（構成要素９０７）。少なくともいくつかの実施形態において、所定のファイルストアオブジェクトに対するデータ書き込みを調整するリーダとして選ばれた特定の格納ノードは、そのファイルストアオブジェクトに対するメタデータ書き込みを調整するリーダとしても選択され得る（メタデータのうち少なくとも一部は、データが格納される格納ノードとは異なる格納ノードに格納され得るが）。

ファイルストアオブジェクトの論理ブロックに対するクライアントからの特定書き込み要求に応じて、論理ブロックがマッピングされた、論理エクステントのマスタエクステントレプリカに対し、内部書き込み要求が出され得る（構成要素９１０）。従って、例えば、クライアント要求を受信したアクセスノードは、例えば適切なメタデータサブシステムノードから抽出したメタデータを使用して、最初に論理ブロックのマスタエクステントレプリカを特定する必要があり、それからマスタレプリカを格納する格納ノードに対し、内部書き込み要求を出し得る。内部書き込み要求の受信に応じて、リーダノードは、レプリカグループメンバー間に書き込み作業負荷を複製するために、コンセンサスベースステート管理プロトコルのインタラクションを開始し得る（構成要素９１３）。少なくともいくつかの実施態様において、ステート変更のログ記録を複製するためにコンセンサスベースプロトコルが使用され、そして当該ステート自体の表現は、消失訂正符号複製を使用して、または完全複製を使用して、複製され得る。プロトコルインタラクションの結果として書き込みがコミットされた場合に、例えばクォーラムのレプリカグループメンバーにおいて書き込みが成功した場合に、いくつかの実施形態において、ついに要求クライアントに対し書き込み要求が成功したことが知らされ得る。別の実施形態において、少なくともいくつかの種類の動作及びいくつかのファイルシステムプロトコルに関して、クライアントの要求が成功したか否かに関する開示は、必ずしもクライアントに提供され得ない。その代わりに、例えばクライアントは、不成功と表示される動作を再試行することを期待され得る。

図１０は、少なくともいくつかの実施形態による、分散ファイルシステム格納サービスのアクセスサブシステムノードにおいてメタデータをキャッシュするために実行され得る動作の態様を例示するフロー図である。構成要素１００１に示されるように、クライアントが分散ファイル格納サービスのアクセスサブシステムノードの集合に対してファイルストア関連要求を送ることを可能にするサービスエンドポイントアドレスが設定され得る。いくつかの実施形態において、前述のように、隔離仮想ネットワーク内でのみアクセス可能なプライベートＩＰアドレスが、アクセスノードに割り当てられ得る。別の実施形態において、非ＩＶＮクライアントによりアクセス可能なパブリックＩＰアドレスが、同様にまたは代わりに使用され得る。アクセスサブシステムノードは、１つまたは複数の業界標準ファイルシステムプロトコル（例えば１つまたは複数のバージョンのＮＦＳ、ＳＭＢ、ＣＩＦＳ等）に準拠する様々な種類の命令、システムコール、またはＡＰＩ呼び出しに応答するように構成され得る。いくつかの実施形態において、所定のアクセスサブシステムノードは、複数のこのような規格またはプロトコルに従ってフォーマットされた命令に応答することが可能であり得る。一実施形態において、プロプライエタリファイルシステムインターフェイスが、同様にまたは代わりに対応され得る。

ＡＰＩ／プロトコルのうちの１つに従ってフォーマットされた、特定のファイルストアオブジェクトＦ１に対する命令（例えば作成、読み出し、書き込み、変更、再構成、または削除命令）が、特定のアクセスノードＡＮ１において受信され得る（構成要素１００４）。ＡＮ１は、例えばネットワーク識別（例えば発信元ネットワークアドレス）、ユーザ識別（例えばユーザアカウント識別子）、または他の要素に基づいて、認証及び／または認可動作の集合を実行し（構成要素１００７）、命令を受諾するか拒否するかを決定し得る。

命令が認証／認可検査を通過した場合、ＡＮ１は、要求された動作を実行するために使用される、Ｆ１に関するメタデータの取得先となるメタデータノードＭＮ１を特定し得る（構成要素１０１０）。アクセスノードＡＮ１は、それからＭＮ１に対しメタデータ要求を送り得る（構成要素１０１３）。いくつかの実施形態において、適切なメタデータノードの識別自体は、例えば格納オブジェクトと他のメタデータノード間のマッピングを管理するメタデータノードに対する別の要求の送信を伴い得る。それからファイルストアオブジェクトＦ１に関するメタデータのブロックが、ＡＮ１において取得され得る。ＡＮ１は、メタデータを、メタデータのブロックが破棄される（失効の可能性のため）、または再有効化される必要のある時を示すキャッシュタイムアウト設定と共に、ローカルメタデータキャッシュに格納し得る（構成要素１０１６）。少なくともいくつかの実施形態において、メタデータのブロックを他の目的のために（例えばＦ１が削除された時に、別のファイルストアオブジェクトＦ２のメタデータを格納するために）再利用しリサイクルしてもよい時を決定するために、キャッシュタイムアウト間隔は、メタデータノードにおいて使用されるメタデータブロック再割り当てタイムアウト設定よりも小さい値に設定され得る。

ＡＮ１は、受信したメタデータのブロックを使用して、読み出し／書き込み要求の対象となる特定の格納ノードＳＮ１を同定し、適宜内部要求を送り得る（構成要素１０１９）。キャッシュタイムアウト時間が経過する前に、ＡＮ１は、さらなるＡＰＩ／プロトコルの呼び出しから生じ得る追加内部要求を出すために、キャッシュされたメタデータのブロックを再利用し得る（構成要素１０２２）。いくつかの実施形態において、キャッシュタイムアウト時間の経過時に、メタデータのブロックは、削除され得る、または無効と示され得る。少なくとも一実施形態において、メタデータを単に破棄する代わりに、アクセスノードは、例えば当該メタデータの取得元であるメタデータノードに対し別の要求を送信することにより、当該メタデータを再有効化し得る。

単一ページ更新の条件付き書き込み
前述のように、少なくともいくつかの実施形態において、ファイル格納サービスは、数百から数千のクライアントからの、数千のファイルストアオブジェクトを対象にする可能性のある大きな数の同時動作を処理するように設計され得る。原子性及び一貫性を確保するための従来のロックベース機構は、ロックシステム自体がボトルネックになり得るため、このような高処理高同時性の環境においては機能し得ない。従って、後述されるように、少なくともいくつかの実施形態において、同時性制御のために１つまたは複数の楽観的スキームが使用され得る。初めに、単一ページ書き込み（すなわち変更が単一論理エクステントの単一ページに限られた書き込み要求）に関する同時性制御機構が説明され、その後、複数ページ書き込みを原子動作として実行するために使用可能な分散トランザクション機構が説明される。

少なくともいくつかの実施態様において、前にも説明されたように、所定のファイルストアのデータ及びメタデータを格納するために使用される物理ページは、対応オブジェクトの論理ブロックとはサイズが異なり得る。同時に、書き込み動作は一般に、任意のオフセットを対象とし、任意のサイズの書き込みペイロードを有し得る。例えば、少なくともいくつかのファイルシステムプロトコル／ＡＰＩに関して、ファイルのエンドユーザの視点からすると、ファイルに対する単一書き込みは、ファイル内の任意の所望のバイトレベルオフセットにおいて開始するデータを変更し、そのバイトレベルオフセットから開始する任意の数のバイトを変更し得る（または初めての書き込みを行い得る）。しかしながら、いくつかの実施形態において、ファイル格納サービスの格納サブシステムは、物理ページを原子性単位として扱い得る。例えば、実施複雑度を低減するために、ページは、格納サブシステムの内部読み出し及び書き込みＡＰＩが対応する最小粒度を表し得る。従って、エンドユーザに公開されるファイルストアＡＰＩの柔軟性と、格納サブシステムが対応する内部動作に対する制約との間に、不一致が生じ得る。よって、このような実施形態において、格納サブシステムのクライアント（例えばアクセスノードまたはメタデータノード）は、任意の書き込み要求を、ページレベルの内部書き込み動作に変換することを強いられ得る。少なくともいくつかの実施形態において、外部クライアント要求に直接起因し得ない少なくともいくつかの内部メタデータ操作は、いくつかの事例において、メタデータの所定のページのごく一部のみを変更する必要があり得る。このようなメタデータ書き込み要求もまた、ページ粒度において実施される必要があり得る。

従って、物理ページに対する少なくともいくつかの書き込み動作は、読み出し‐変更‐書き込みシーケンスとして実行され得る。図１１は、少なくともいくつかの実施形態による、書き込みオフセット及び書き込みサイズが時に物理格納の原子単位の境界と整列し得ないファイル格納サービスにおいて実行され得る読み出し‐変更‐書き込みシーケンスの例を示す。示されるように、ファイルストアオブジェクト（ファイルまたはメタデータ構造等）は、論理ブロック（ＬＢ）１１０２Ａ、１１０２Ｂ、１１０２Ｃを含むＬＢ１１０２の集合として組織され得る。各論理ブロックは、格納サブシステムのエクステント（例えば１つの論理エクステント及び複数の物理エクステントレプリカ）内のページ集合に対応付けられ、当該ページは格納サブシステムのＡＰＩに関する原子性単位を表す。例えば、描かれた実施形態において、論理ブロック１１０２Ａは、エクステント１１６４の物理ページ（ＰＰ）１１１２Ａ、１１１２Ｂ、１１１２Ｃ、１１１２Ｄにマッピングされる。

特定の書き込み要求１１６０に応じて、単一ページの一部のみ（書き込み要求１１６０Ａの場合ＰＰ１１１２Ａの網掛け部分、書き込み要求１１６０Ｂの場合ＰＰ１１０２Ｄの網掛け部分等）が実際に変更され得る。しかしながら、描かれた実施形態において、格納サブシステムＡＰＩは部分的ページ書き込みを許容し得ないため、示されるそれぞれの書き込み要求は、対応物理ページに対する読み出し‐変更‐書き込みシーケンスに変換され得る。従って、クライアント（例えば内部書き込み要求１１６０を出したアクセスノードまたはメタデータノード）は、意図された部分的書き込みを実行するには、最初に対象ページを読み出し、所望の変更を適用し、それからページ全体の書き込みを送らなければならないということを判断し得る。書き込み要求１１６０Ａに対して、ページ１１１２Ａの読み出しと、クライアントにおけるページ１１１２Ａのコンテンツの局所的変更と、全ページ１１１２Ａの書き込みとを含む読み出し‐変更‐書き込みシーケンスＲＭＷ１１７７Ａが実行され得る。書き込み要求１１６０Ｂに対して、ページ１１１２Ｄの読み出し、続いて変更、それから全ページ１１１２Ｄの書き込みを伴うＲＭＷ１１７７Ｂが実行され得る。

同一の物理ページに対し要求される同時または略同時更新の可能性を考えると、所定物理ページのコンテンツはＲＭＷシーケンスの読み出しとＲＭＷシーケンスの書き込みの間に変更されていないことを、格納サービスが保証する必要があり得る。少なくともいくつかの実施形態において、格納サブシステムにおける複製ステート管理のために実行され得る論理タイムスタンプ機構は、後述される逐次一貫性を保証するのに使用され得る。

先に述べられ、図５において示されるように、所望するレベルのデータ耐久性を達成するために、論理エクステントのレプリカグループが少なくともいくつかの実施形態において使用され得る。図１２は、少なくともいくつかの実施形態による、エクステントレプリカグループに対するコンセンサスベースの複製ステートマシンの使用を例示する。描かれた実施形態において、論理エクステントＥ１に関して、格納ノード１３２におけるマスタレプリカ１２６４Ａと、格納ノード１３２Ｂ、１３２Ｃ、１３２Ｄそれぞれにおける非マスタレプリカ１２６４Ｂ、１２６４Ｃ、１２６４Ｄという、４つのエクステントレプリカが示される。別の論理エクステントＥ２に関して、格納ノード１３２Ｄにおけるマスタエクステントレプリカ１２６５Ｃと、２つの非マスタレプリカ１２６５Ａ（格納ノード１３２Ａにおける）、１２６５Ｂ（格納ノード１３２Ｂにおける）とが示される。Ｅ１レプリカ上の様々な動作を調整するために、コンセンサスベースの複製ステートマシン１２３２Ａがノード１３２Ａ（マスタレプリカが格納されるノード）により使用され、そしてＥ２レプリカ上の動作を調整するために、別のコンセンサスベースの複製ステートマシン１２３２Ｂがノード１３２Ｄ（マスタレプリカ１２６５Ｃが属するノード）により使用され得る。

描かれた実施形態において、ステートマシン１２３２Ａは論理クロック１２２２Ａを使用し、そしてステートマシン１２３２Ｂは別の論理クロック１２２２Ｂを使用し得る。少なくともいくつかの実施形態において、論理クロックは、対応するステートマシンを使用して管理される様々な動作の相対的順序を示すために使用され、実時間または任意の特定の物理時計に直接関係し得ない。従って、例えば、特定論理クロック値ＬＣ１は、ステートマシン１２３２Ａを使用して調整される書き込み動作のコミットに対応付けられ、別の論理クロック値ＬＣ２は、レプリカグループから読み出し動作に対する応答が提供された時を示し得る。この例においてＬＣ１＜ＬＣ２である場合、格納サブシステムの観点からすると、書き込み動作は読み出し動作よりも前に完了したことが示される。論理クロックの値は、本明細書において「論理タイムスタンプ」または「動作シーケンス番号」（論理クロック値が、対応複製ステートマシンを使用して様々な読み出しまたは書き込み動作が完了したシーケンスを示し得るため）とも称され得る。いくつかの実施態様において、論理クロックとして、マスタレプリカが内在する格納ノードにて実行される整数カウンタが使用され、そしてその格納ノードは、クロック値に対する変更の責任を担い得る（例えば、ステートマシンを使用して読み出しまたは書き込み動作が完了した時はいつも、当該カウンタの値が増加され得る）。

様々な実施形態において、格納ノードは、ステートマシン１２３２から取得した論理タイムスタンプ値を、前述のＲＭＷシーケンスの読み出し及び書き込み要求に対応付け、論理タイムスタンプを使用して、特定の単一ページ書き込みをコミットするか、アボートするかを決定し得る。図１３は、少なくともいくつかの実施形態による、いくつかの種類の書き込み動作に使用され得る条件付き書き込みプロトコルに関わる例示的インタラクションを示す。示されるように、特定の書き込み動作に対応する読み出し‐変更‐書き込みシーケンスの一環として、格納サブシステムのクライアント１３１０（アクセスノードまたはメタデータノード等）は、格納ノード１３２（例えばページが属するエクステントのマスタレプリカが格納されるノード）に対し読み出しページ要求１３５１を送り得る。格納ノードは、要求されたページのコンテンツ、並びに読み出し動作に割り当てられた読み出し論理タイムスタンプ（ＲＬＴ）を含む読み出し応答１３５２を提供し得る。ＲＬＴは、例えばエクステントに使用されている複製ステートマシンから取得され得る。

ＲＭＷシーケンスについて続けると、格納サブシステムクライアント３１０は、続いて格納ノード１３２に対しページ全体の書き込み要求１３６１を送り、読み出し応答に含まれていたＲＬＴを含め得る。格納ノードは、ＲＬＴが生成された後に、ページの更新が成功したか否かを判定し得る。ＲＬＴが生成されて以来、ページが更新されていない場合、要求された書き込みは完了され、成功を示す書き込み応答１３６２が格納サブシステムクライアントに提供され得る。ＲＬＴが生成された後に、別の介入書き込み要求の結果としてページが更新された場合、書き込み要求は拒否され得る。いくつかの事例においてこのような書き込み要求を受諾することは、データ不整合につながり得る。なぜなら、例えば、所定の書き込み要求に応じて書き込む特定のデータＤ１は、前にページから読み出された値Ｒ１に依存し、このＲ１は当該介入書き込みにより上書きされた可能性がある。いくつかの実施態様において、クライアント１３１０からの書き込み要求が拒否された場合、書き込みがアボートされたことを示す書き込み応答１３６２が、クライアントに提供され得る。別の実施態様においては、書き込み応答は全く提供され得ない。書き込みがアボートされた場合、いくつかの実施形態において、クライアント１３１０は、例えば書き込みが最終的に成功するまで、または書き込み試行がある閾値回数失敗するまで、同じページに対し１つまたは複数の追加ＲＭＷシーケンスを開始し得る。

ＲＬＴが生成された後に、同一ページに対する介入書き込みが成功したか否かを検出するために、いくつかの実施形態において、書き込み論理タイムスタンプを格納する書き込みログバッファが、格納ノード１３２において実行され得る。図１４は、少なくともいくつかの実施形態による、条件付き書き込みプロトコルを実施するために確立され得る例示的書き込みログバッファを示す。描かれた実施形態において、例えばエクステントのマスタレプリカが格納される格納ノードにおいて、論理エクステントごとに、それぞれの循環書き込みログバッファ１４５０が保持される。エクステントＥ１のマスタレプリカ１４１０Ａを管理する格納ノード１４３２Ａにより、Ｅのための循環バッファ１４５０Ａが保持され、そしてＥ２のマスタレプリカ１４１０Ｂを格納する格納ノード１４３２Ｂにより、循環バッファ１４５０Ｂが保持される。各循環バッファは、バッファ１４５０Ａ内のレコード１４６０Ａ、１４６０Ｂ、１４６０Ｃ、１４６０Ｄ、及びバッファ１４５０Ｂ内のレコード１４６０Ｋ、１４６０Ｌ、１４６０Ｍ、１４６０Ｎ等、複数の書き込みログレコード１４６０を含む。描かれた実施形態における各ログエントリ１４６０は、コミットした（すなわち成功した）ページ書き込みのそれぞれの開示を含み、当該開示は、書き込みが行われたページの識別子と、書き込みの完了に対応付けられた論理タイムスタンプと、書き込みが行われた対象クライアントとを示す。従って、バッファ１４５０Ａにおいて、レコード１４６０Ａ〜１４６０Ｄは、識別子１４１５Ａ〜１４１５Ｄを有するページそれぞれに対し、それぞれの書き込み論理タイムスタンプ１４１７Ａ〜１４１７Ｄにより示される順序で、それぞれの識別子１４１９Ａ〜１４１９Ｄを有するクライアントのために、書き込みが行われたことを示す。同様に、バッファ１４５０Ｂは、識別子１４１５Ｋ〜１４１５Ｎを有するページそれぞれに対し、それぞれの書き込み論理タイムスタンプ１４１７Ｋ〜１４１７Ｎにより示される順序で、それぞれの識別子１４１９Ｋ〜１４１９Ｎを有するクライアントのために、書き込みが行われたことを示す。少なくともいくつかの実施形態において、書き込みログバッファは、高速アクセスのためにメインメモリに保持され得る。少なくとも一実施態様において、所定のレコード１４６０の書き込み論理タイムスタンプは、バッファ内のそのレコードの相対位置により非明示的に示され得る。従って、このような実施態様において、書き込み論理タイムスタンプの明示値が、バッファに格納される必要はない。いくつかの実施形態において、ログバッファは、永続性メモリに格納され、スピード検索のために、タイムスタンプ値により、ページ識別による、及び／またはクライアント識別子により設定されたインデックスを有し得る。様々な実施形態において、図１４に示されるものと同様の書き込み論理タイムスタンプ情報が、例えば物理ページ粒度で、またはエクステント粒度で、またはその他のレベルで等、異なる粒度で保持され得る。

格納ノード１４３２が読み出し‐変更‐書き込みシーケンスの特定の書き込みを受諾するか拒否するか判定する必要があり、かつ書き込み要求が当該シーケンスの読み出し動作の読み出し論理タイムスタンプ（ＲＬＴ）を含む場合、当該格納ノードは、書き込みログバッファを調べて、ＲＬＴよりも大きな論理タイムスタンプを有する任意の書き込みが同一ページに対して起こったか否かを確かめ得る。例えば、ページＰ１に対するＲＭＷシーケンスの書き込み要求に対応するＲＬＴ値がＶ１であり、レコード１４６０間の最小書き込み論理タイムスタンプはＶ２＜Ｖ１であり、バッファ内にＶ３＞Ｖ１を有するレコードがない場合には、格納ノード１４３２は、ページＰ１に対する介入書き込みは起こらなかったと結論付け、そしてＲＭＷの書き込みが受諾され得る。ページＰ１に対する書き込み論理タイムスタンプＶ３＞Ｖ１を有するエントリがある場合、描かれた実施形態において、書き込みは拒否またはアボートされ得る。循環バッファ１４５０内のレコード間の最小書き込み論理タイムスタンプＶ２がＶ１より大きい場合、ＲＬＴが生成された後にＰ１に対するいくつかの書き込みが成功し得たが、それらの書き込みログレコードが上書きされた可能性がある（例えばバッファの領域制限により）ことを示し得るため、少なくともいくつかの実施形態において、このようなシナリオにおいてはＰ１に対する書き込み要求は同様に拒否され得る。ＲＭＷの書き込み要求が受諾された場合、新たな書き込みログレコード１４６０が、書き込みのコミットに対応した書き込み論理タイムスタンプと共に、循環書き込みログバッファに追加され得る（前に生成されたログレコードを上書きする可能性あり）。（更新する必要のあるレプリカの数、及び使用されている複製プロトコルに応じて、無事に書き込みを完了すなわちコミットするのに必要なだけのレプリカに対し変更が伝播されるまでに、いくらか時間がかかり得ることに留意されたい。）

描かれた実施形態において循環バッファが使用されるため、バッファに使用される総メモリ量は小さくとどまり、そして古い書き込みログレコードは徐々に、より有用な新しい書き込みログレコードにより上書きされる。特定の読み出し‐変更‐書き込みシーケンスの書き込み動作は一般に、読み出しの後に極めて早く実行されることが予期されるため、古い書き込みログレコードは通常、ＲＭＷシーケンスの書き込みをコミットするかアボートするかを決定する際、あまり役に立ち得ない。しかしながら、前述のように、エクステントに対する書き込みは頻繁に起こるため、潜在的に有用な書き込みログレコードが循環バッファ内で上書きされ得る場合が、いくつかのシナリオにおいてあり得る。いくつかの実施形態において、格納サービスは、このような上書きのために拒否される書き込みの数を記録し得る。すなわち、読み出し論理タイムスタンプとバッファの最早論理タイムスタンプとの比較（及び読み出し論理タイムスタンプが最早論理タイムスタンプより前であるという後続判断）の結果として特に生じる書き込み拒否率が監視され得る。いくつかのこのような実施形態において、循環ログバッファのサイズは動的に変更され得る。例えば、バッファ領域制約に起因する書き込み拒否率がある閾値を超えたという判断に応じて、当該バッファサイズは増大され得る、あるいは単純に高作業負荷期間中に当該バッファサイズは増大され得る。同様に、低作業負荷期間中に、またはバッファサイズ制約に起因する拒否率がある閾値よりも低いという判断に応じて、バッファサイズは縮小され得る。いくつかの実施形態において、他の種類のバッファ（すなわち非循環バッファ）が使用され得る。少なくとも一実施形態において、クライアント識別子は、書き込みログバッファに格納され得ない。いくつかの実施形態において、読み出し、並びに書き込みを記録するために、図１４に示されるものと同様のバッファが使用され得る。少なくとも一実施形態において、バッファの長さは、未処理の読み出し‐変更‐書き込みシーケンスの読み出しのタイミングに基づいて、動的に調整され得る。例えば、特定のＲＭＷシーケンスの読み出しが時間Ｔ１に起こり、そのシーケンスの対応書き込み要求が受信される前のある時間Ｔ２にバッファが一杯になった場合、対応書き込みの受諾に関して正しい判断を行うために、バッファサイズは増大され得る（例えばある最大長閾値及び／またはある最大時間閾値内で）。いくつかのこのようなシナリオにおいて、対応書き込みが受信された時、例えば時間Ｔ３に、バッファサイズは前の長さに再び縮小され得る。

少なくとも一実施形態において、格納サービスは、各ページレベルでバージョン管理情報を保持し、バージョン管理情報を使用してＲＭＷの書き込みを受諾するべきか否か判断し得る。例えば、各エクステントレベルで書き込み動作のログバッファを保持する代わりに、１つのこのようなバージョン管理手法において、各ページレベルでログエントリが保持され得る。そのため、ＲＭＷの書き込みが対応読み出しと同じバージョンを対象としているか否か判定することが可能になる。読み出し以降に新バージョンが作成された場合、書き込みは拒否され得る。

図１５は、少なくともいくつかの実施形態による、分散ファイルシステム格納サービスにおいて条件付き書き込みプロトコルを実施するために実行され得る動作の態様を例示するフロー図である。構成要素１５０１において示されるように、格納サブシステムのクライアントＣ（アクセスノードまたはメタデータノード等）において、特定のファイルストア動作を実行するために、特定のページＰに対し読み出し‐変更‐書き込みシーケンスを実施することが決定され得る。いくつかの実施形態において、ページ全体が変更されているとしても、全ての単一ページ書き込みはデフォルトで読み出し‐変更‐書き込み動作に変換され得る。よって、このような実施形態において、任意のページに対する任意の書き込みはＲＭＷシーケンスに変換され得るため、ＲＭＷが必要か否かに関する判断が要求され得る。別の実施形態において、ページ全体を変更する書き込みは、ＲＭＷシーケンスへの変換を必要とし得ず、一方、ページの一部のみを変更する書き込みは、ＲＭＷシーケンスに変換され得る。

構成要素１５０４に示されるように、ＲＭＷシーケンスの一環として、格納ノードＳＮ１（例えばＰが属するエクステントのマスタレプリカが格納されるノード）のＣから、Ｐに対する読み出し要求が受信され得る。例えばＰのエクステントを管理するために使用されている複製ステートマシンから、同一エクステントにおける他の読み出し及び書き込みに相対して読み出しが実行された順序を示す、読み出し要求に対応する読み出し論理タイムスタンプＲＬＴが取得され得る（構成要素１５０７）。読み出し要求を送ったクライアントＣに対し、ＲＬＴが提供され得る。

続いて、ページＰに対するＲＭＷシーケンスの書き込み要求ＷＲ１が、ＳＮ１のＣから受信され得る（構成要素１５１０）。書き込み要求は、構成要素１５０７の読み出し応答においてＣに提供されたＲＬＴ値、並びに書き込みペイロード（すなわちＰに適用する変更）を含み得る。格納ノードＳＮ１は、例えば最近の成功書き込みに対応付けられた論理タイムスタンプを格納する書き込みログバッファのコンテンツを調べることにより、ＲＬＴが生成された後にページＰが変更されたか否か判定し得る。ＲＬＴが生成されて以来、Ｐが変更されなかったと判定された場合（構成要素１５１３）、Ｐに対し適切な変更を行い、適切な数のレプリカに対し変更を伝播することにより、書き込みが実行され得る（構成要素１５１６）。書き込みの完了に対応する書き込み論理タイムスタンプは、描かれた実施形態において書き込みログバッファに格納され、そして少なくともいくつかの実施形態において、書き込み完了の開示がＲＭＷシーケンスを発したクライアントに対し送信され得る。いくつかの実施態様において、書き込み論理タイムスタンプは、完了開示の一環として、クライアントに提供され得る。ＲＬＴが生成された後にＰが変更されたと判定された場合（同様に構成要素１５１３に該当する動作において）、書き込みは拒否され、そしていくつかの実施形態において「書き込みアボート」応答がクライアントに対し送信され得る。

順序設定済みノードチェーンを使用する分散トランザクション
前述の条件付き書き込み技術は、様々な実施形態において、単一ページ書き込み動作において逐次一貫性を確保するために使用され得る。しかしながら、分散ファイル格納サービスのいくつかの種類の動作（削除、名前変更等）に関しては、メタデータ及び／またはデータの複数ページが原子的に変更される必要があり得る。すなわち、全ての関係ページに対する全ての変更がコミットされるか、全ての変更が拒否される必要がある。少なくともいくつかの実施形態において、当目的のために、分散トランザクションを伴うよりハイレベルな楽観的一貫性施行機関が使用され得る。このような実施形態において分散トランザクションを実行するために、コーディネータノード（例えば関係するメタデータ及び／または格納ノードのうちの１つ）が選択され得る。コーディネータは、変更に参加する格納ノードを特定し、個別のページレベル変更がそれぞれの格納ノードにおいて受諾されるか拒否されるかに関して調査するシーケンスを決定し、それから、格納ノードそれぞれが自身のページレベル変更に関して各自のコミット／アボート判定を行うことが可能な格納ノード間の順序設定済み動作シーケンスを開始し得る。全ての参加格納ノードが、自身の局所的変更はコミット可能であると判定した場合、トランザクション全体がコミットされ得る。一方、参加格納ノードのうちのいずれか１つが、自身の局所的ページレベル変更はコミット不可能であると判定した場合、トランザクション全体がアボートされ得る。コーディネータ及び参加ノードの動作の様々な態様に関する詳細が、下記に提供される。

図１６は、少なくともいくつかの実施形態による、ファイル格納サービスにおいて分散トランザクションのコミットに至り得る例示的メッセージフローを示す。例えばアクセスサブシステムノードまたはメタデータノードにおいて、特定のファイルストア動作は複数のページに対する書き込みを要するという判断が行われ得る。対応する複数ページ書き込み要求１６１０が生成され得る。本明細書において、変更されるページの集合は、トランザクションの「対象ページ」と称され得る。対象ページに対する書き込みの集合を原子的に実行するために、分散トランザクションに対するコーディネータノード１６１２として、格納サービスの特定のノード（様々な実施形態におけるアクセスノード、メタデータノード、または格納ノード）が選択され得る。コーディネータは、変更対象のページの集合と、ページレベル変更が開始または実行される格納ノードの集合（例えば対象ページを含むマスタレプリカエクステントを格納する格納ノードの集合で、コーディネータが格納ノードの場合はコーディネータも含まれ得る）とを特定し得る。コーディネータノードの選択には、様々な技術のうちのいずれかが使用され得る。例えば、いくつかの実施形態において、変更するページの集合のうちランダムに選択されたページが属する格納ノードがコーディネータとして選択され得る一方、別の実施形態においては、コーディネータ候補ノードにおける作業負荷レベルを考慮して、サービスの格納ノード間にトランザクション調整に対応付けられた作業を分配する試みが行われ得る。

少なくともいくつかの実施形態において、デッドロック回避技術に従って、コーディネータ１６１２により、変更対象ページがロックされるべきシーケンスが決定され得る。例えば、トランザクションにおいて変更するページ及びエクステントの識別子がデッドロック分析モジュールに提供され、そしてデッドロック分析モジュールは、ロック順序を決定するために、ある選択された並び替え順序（例えばエクステントＩＤ、ページＩＤ、及び／または他の要素の連結に基づいた辞書式並び替え順序）に基づいて、識別子の並び替えを行い得る。ファイルストアの全ての分散トランザクションにわたって同一の並び替え順序が一貫して使用され、その結果、任意の所定の対のページＰ１、Ｐ２に対するロックが常に同じ順序で要求され得る。例えば、デッドロック分析モジュールが、トランザクションＴｘ１に関してＰ１に対するロックはＰ２に対するロックの前に確保されるべきであると示す場合、デッドロック分析モジュールは、その他のトランザクションＴｘ２に関してＰ２に対するロックはＰ１に対するロックの前に確保されるべきであるとは決して示さないため、デッドロックが回避される。

少なくともいくつかの実施形態において、分散トランザクションの準備段階の一環として、選ばれたコーディネータノード１６１２はまた、対象ページに対し読み出し要求を出し、前述の技術に従って、これらの読み出しの対応読み出し論理タイムスタンプ（ＲＬＴ）を取得し得る。後述されるように、対象ページが属する格納ノードそれぞれにおいて、ページレベルコミット判定を行うために、読み出し論理タイムスタンプが使用され得る。

それから選択されたコーディネータノード１６１２は、対象ページがそれぞれのページレベルコミット判定に関して分析される順序の指示と、その順序でページレベルコミット判定を行う責任を担う格納ノードを含むノードチェーンと、ページに対して行う実際の変更（書き込むバイト）と、対象ページそれぞれのＲＬＴとを含むトランザクション準備（Ｔｘ準備）メッセージ１６４２Ａを構成し得る。ノードチェーン１６０２が、図１６において例示される。ノードチェーンの最後または末端メンバー（例えばノードチェーン１６０２におけるノード１６３２Ｃ）は、自身の局所的ページレベルコミット判定がトランザクション全体のコミットにつながり得ることから、「コミット決定者」または「決定者」ノードとして指定され得る。

コーディネータは、Ｔｘ準備メッセージ１６４２Ａを、対象ページの少なくとも１つ（図１６の論理エクステントＥ１のページＰ１）を格納する、ノードチェーン１６０２の格納ノード１６３２Ａといったノードチェーンの第１ノードに送信し得る。ノード１６３２Ａは、ページＰ１に対する変更がコミット可能か否か判定を行うために、例えばＰ１のＲＬＴを使用して、局所的ページレベルコミット分析を行い得る。条件付き書き込み及びＲＭＷシーケンスに関して前述されたものと同様の技術を使用して、Ｐ１のＲＬＴが取得されて以来Ｐ１が変更されなかった場合、Ｐ１に対する変更はコミット可能であると判定され得る。ＲＬＴが取得された後にＰ１が変更された場合、変更は拒否される必要があり得る（拒否シナリオは図１７において例示され、後述される；図１６は全てのページレベルコミット判定が肯定的であるシナリオを例示する）。Ｐ１に対し提案変更がコミット可能であると仮定すると、ノード１６３２Ａは、Ｐ１をロックし（例えばエクステントＥ１に使用される複製ステートマシンにより管理されるロックを確保）、そして「インテントレコード」を永続性格納領域に格納する。ページＰ１がロックされている限り、描かれた実施形態において、その他のトランザクションまたはその他のＲＭＷシーケンスのためにＰ１に対し読み出しまたは更新を行うことは不可能である。インテントレコードは、ノード１６３２ＡがＰ１に対し提案変更を行う意図があり、そして残りのチェーンメンバーが同様にそれぞれのページレベル変更を行うことに同意可能な場合には、実際に変更を行い得ることを示し得る。ノード１６３２Ａはそれから、ノードチェーンの次のノード１６３２Ｂに対し、Ｔｘ準備メッセージ１６４２Ｂ（１６４２Ａのコンテンツと同様または同一であり得るコンテンツを含む）を送信し得る。

論理エクステントＥ５のページＰ７に関して、ノード１６３２Ｂにおいて同様の局所的ページレベルコミット分析が行われ得る。ノード１６３２Ｂは、自身の局所的ページレベル変更がコミット可能であると判定した場合（例えばＴｘ準備メッセージ１６４２Ｂに含まれていたＰ７のＲＬＴを使用して）、ノード１６３２Ｂは、Ｐ７に対するロックを確保し、自身のインテントレコードを格納し、そしてＴｘ準備メッセージ１６４２Ｃ（１６４２Ｂと同様または同一）を決定者ノード１６３２Ｃへ送信し得る。

決定者ノード１６３２Ｃ（チェーン内の末端または最後のノード）は、エクステントＥ８のページＰ９に関する自身のページレベルコミット分析を行い得る。ページＰ８に対する提案変更がコミット可能である場合（例えばＰ８のＲＬＴがコーディネータにより取得されて以降、Ｐ８に対する書き込みが行われていなかった場合）、決定者は、トランザクション全体をコミットすることを決定し、Ｐ８に対する提案変更を実行または開始し得る。決定者ノードは、分散トランザクションをコミットすることを示すＴｘコミットメッセージ１６４４Ａを生成し、チェーンの他のノードへ当メッセージを送信し得る。描かれた実施形態において、Ｔｘコミットは、Ｔｘ準備メッセージの伝播とは逆の順序で、順次伝播され得る。別の実施形態において、Ｔｘコミットは、非決定者ノード及び／またはコーディネータのうちの一部または全てに対し、並行して送信され得る、あるいは図１６に示されるものとは異なる順序で送信され得る。

チェーン１６０２の非決定者ノードは、Ｔｘコミットメッセージを受信すると、自身の局所的ページレベル変更を実行または開始し、局所的対象ページに対するロックを解除し（例えばノード１６３２Ｂの場合はＰ７、ノード１６３２Ａの場合はＰ１）、ページ用に前に生成したインテントレコードを削除し、そして（必要であれば）Ｔｘコミットメッセージを別のノードに送信し得る（例えばノード１６３２Ｂはノード１６３２ＡへＴｘコミットメッセージ１６４４Ｂを送信し、ノード１６３２ＡはコーディネータへＴｘコミットメッセージ１６４４Ｃを返信し得る）。コーディネータノード１６１２は、Ｔｘコミットメッセージを受信すると、いくつかの実施形態において、複数ページ書き込み１６１０の要求者に対して、書き込み成功応答１６５０を送信し得る。デッドロックを回避するために決定された所定の順序で局所的ページレベルコミット分析を行い、Ｔｘ準備メッセージの受信かつ局所的コミット分析の成功時にのみページをロックし、そしてインテントレコードを永続性格納領域（例えばインテントレコードの責任を担う格納ノードが、トランザクションが完了する前に起こり得る障害の結果置き換えられる場合においても、インテントレコードにアクセス可能な永続性格納領域）に格納することに関する前述の技術は全て、分散格納サービスにおいて複数書き込みの原子性を要求する動作の効率性及び回復性を向上するのに役立ち得る。

少なくともいくつかの実施形態において、所定の分散トランザクションに関して特定されたノードチェーンの格納ノードのうちのいずれか１つは、自身の局所的コミット分析に基づいて、自身の局所的ページに対する提案変更は受諾不可能であることを判定し、そのためトランザクション全体のアボートを開始し得る。図１７は、少なくともいくつかの実施形態による、ファイル格納サービスにおいて分散トランザクションのアボートに至り得る例示的メッセージフローを示す。図１６の場合、ノード１６１２は、複数ページ書き込み要求１６１０に応じて試みられる分散トランザクションのコーディネータとして選択され得る。コーディネータは、例えば、局所的ページレベルコミット判定を行いロックを確保する順序を決定し、ノードチェーン１６０２を生成し、Ｔｘ準備メッセージ１６４２Ａを作成する等、図１６の文脈において説明されるものと同様の、トランザクション動作の準備集合を実行し得る。コーディネータ１６１２により、Ｔｘ準備メッセージがチェーンの第１ノード１６３２Ａへ送信され得る。

ノード１６３２Ａは、自身の局所的コミット分析を実行し、エクステントＥ１のページＰ１に対する提案変更が受諾可能であると判定する。図１６に示されるシナリオのように、ノード１６３２Ａは、Ｐ１に対するロックを確保し、インテントレコードを永続性格納領域に格納し、Ｔｘ準備メッセージ１６４２Ｂをチェーン１６０２の次のノード１６３２Ｂへ送信し得る。図１７に例示されるシナリオにおいて、エクステントＥ５のページＰ７に対する提案変更は、例えばコーディネータ１６１２によりＰ７のＲＬＴが取得された後にＰ７に対する変更が成功しているため、受諾不可能であるとノード１６３２Ｂが判定し得る。従って、ノード１６３２ＢがＰ７に対し提案変更を実行する意図があることを示すインテントレコードを格納する代わりに、トランザクションはアボートされるべきであると示すＴｘアボートメッセージ１７４４Ａを生成し得る。描かれた実施形態において、Ｔｘアボートメッセージ１７４４Ａは、受信したＴｘ準備メッセージ１６４２Ｂの送信元のノードに対し送信され得るが、別の実施形態において、Ｔｘアボートメッセージ１７４４Ａは、局所的コミット分析が成功した後にインテントレコードを既に格納済みの他のノードチェーンメンバーに対し、並行して送信され得る。Ｔｘアボートメッセージ１７４４Ａを受信すると、ノード１６３２Ａは、自身のインテントレコードを削除し、ページＰ１に対するロックを解除し、コーディネータ１６１２に対しＴｘコミットメッセージ１６４４Ｃを返信し得る。いくつかの実施形態において、今度はコーディネータ１６１２が、複数ページ書き込みの要求者に対して書き込み失敗応答１７５０を送信し得る。少なくともいくつかの実施形態において、使用されているＡＰＩのセマンティックにより、書き込み失敗応答１７５０と書き込み成功応答１６５０は、いずれも送信され得ない。その代わりに、要求エンティティは、自身の要求が成功したか否かを他の命令を使用して判断し得る（例えばディレクトリリスト作成命令を使用して、削除または名前変更が成功したか否かを判断し得る）。ノードチェーンの全てのノードが、アボートされたトランザクションに参加し得るとは限らないことに留意されたい。例えば、図１７における決定者ノード１６３２Ｃは、分散トランザクションに参加するはずだったことを認識さえし得ない。従って、アボートは、チェーンメンバーのうちのいくつかにおける任意のリソースを無駄に消費して終わらず、その他の技術と比べて、分散トランザクションに対応付けられる全体処理量を削減するのに役立ち得る。

前述のように、いくつかの実施形態において、トランザクション用に特定されたノードチェーンの参加格納ノードのうちの１つ自体が、トランザクションのコーディネータとして選択され得る。少なくともいくつかの実施形態において、コーディネータはチェーンの第１ノードである必要はなく、またコーディネータは必ずしも決定者ノードとは限らない。図１８は、少なくともいくつかの実施形態による、トランザクションのコーディネータとして指定されたノードを含む分散トランザクション参加ノードチェーン１８０４の例を示す。示されるように、ノードチェーン１８０４は、格納ノード１６３２Ａ、１６３２Ｂ、１６３２Ｋ、１６３２Ｃを含み、１６３２Ａはチェーンの第１ノードとして指定され、１６３２Ｃはチェーン内の末端かつ決定者ノードとして指定される。トランザクションの変更を行う対象ページには、ノード１６３２ＡにおけるエクステントＥ１のページＰ１と、ノード１６３２ＢにおけるエクステントＥ５のページＰ７と、ノード１６３２ＫにおけるエクステントＥ６のページＰ４と、ノード１６３２ＣにおけるエクステントＥ８のページＰ９とが含まれる。（図１６、１７、１８の例は全て、各チェーンメンバーにて単一ページのみが変更されるように示されるが、一般に様々な実施形態においては、任意の数のページが各チェーンメンバーにて変更可能である。）ノード１６３２Ｋは、トランザクションコーディネータとしても指定されている。

従って、トランザクションコーディネータという役割で、ノード１６３２Ｋは、チェーンの第１ノード１６３２Ａに対しＴｘ準備メッセージ１８０１を送信し得る。図１６に例示されるシナリオのように、Ｔｘ準備メッセージはノードチェーンに沿って順次伝播され得る。例えば、各中間ノードにおけるそれぞれの局所的ページレベルコミット判定が肯定的であると仮定すると、Ｔｘ準備１８０２がノード１６３２Ａからノード１６３２Ｂへ送信され、Ｔｘ準備１８０３がノード１６３２Ｂからノード１６３２Ｋへ送信され、Ｔｘ準備１８０４がノード１６３２Ｋから決定者ノード１６３２Ｃへ送信され得る。

決定者ノード１６３２Ｃは、Ｔｘコミットメッセージの伝播を逆の順序で開始し得る。例えばＴｘコミットメッセージ１８５１がノード１６３２Ｃからノード１６３２Ｋへ送信され、Ｔｘコミットメッセージ１８５２がノード１６３２Ｋからノード１６３２Ｂへ送信され、Ｔｘコミットメッセージ１８５３がノード１６３２Ｂからノード１６３２Ｂへ送信され得る。トランザクションを完了するために、描かれた実施形態において、ノード１６３２Ａは、最終Ｔｘコミットメッセージ１８０４をコーディネータノード１６３２Ｋへ送信し得る。少なくともいくつかの実施形態において、ノードチェーンの参加ノードからのコーディネータを動的に選択することは、調整作業負荷（例えばＴｘ準備メッセージに必要な情報を収集し分析するトランザクションの準備段階に関連する作業負荷）を格納サブシステムノード間に分配する際、コーディネータを静的に選んだ場合に可能であったであろう分配と比べて、より均等に分配するのに役立ち得る。

少なくともいくつかの実施形態において、図１９を参照して後述されるように、ノードチェーンメンバーそれぞれは、トランザクション後もある時間、トランザクションステートレコードをローカルに格納し得る。ステート情報は、例えばトランザクションが完了（コミットまたはアボートのどちらでも）する前に参加ノードのうちの１つに障害が発生した時に必要となり得る復旧動作中に使用され得る。時間と共に、このようなトランザクションステート情報は、さらに多くのメモリ及び／または格納領域を必要とし得る。従って、古いトランザクションのステート情報に充てられたメモリ及び／または格納領域を解放するために、所定のトランザクションがコミットまたはアボートされた後のある時点で、図１８に描かれた実施形態においてコーディネータノード１６３２Ｋは、Ｔｘクリーンアップメッセージ１８７１、１８７２、１８７３をチェーン１８０４のノードに対し送信し得る。Ｔｘクリーンアップメッセージは、どのトランザクションのステートレコードが格納ノードから削除されるべきか、トランザクションの識別子を示し得る。従って、少なくともいくつかの実施形態において、格納ノードは、Ｔｘクリーンアップメッセージを受信すると、特定されたトランザクションステートレコードを削除し得る。様々な実施形態において、Ｔｘクリーンアップメッセージは、コーディネータから格納ノードチェーンメンバーに対し並行して送信され得る（図１８において提案）、あるいは順次伝播され得る。いくつかの実施形態において、コーディネータは、トランザクションがコミットまたはアボートされてから調整可能または設定可能な時間が経過した後に、所定のトランザクションに関するＴｘクリーンアップメッセージを送信することを決定し、そして当該時間は、様々な格納ノードにおいて古いトランザクションレコードに使用される格納／メモリ領域の測定等、様々な要素に基づいて調整され得る。コーディネータノードは偶然、図１８におけるノードチェーン１８０４のメンバーであるが、コーディネータがノードチェーンのメンバーであろうがなかろうが、コーディネータノードによりＴｘクリーンアップメッセージが送信され得る。いくつかの実施形態において、単一のＴｘクリーンアップメッセージは、トランザクションレコードがクリーンアップされるべきいくつかの異なるトランザクションの指示を含み得る。少なくとも一実施形態において、図１８に示されるようにコーディネータがＴｘクリーンアップメッセージを送信する代わりに、チェーン内のその他の選択されたメンバーがＴｘクリーンアップメッセージを送信する責任を担い得る。このような一実施形態において、例えばチェーンの第１メンバー（例えば図１８におけるノード１６３２Ａ）により、Ｔｘクリーンアップメッセージは送信され得る。

任意の分散コンピューティング環境、特に、数千の汎用コンピューティングデバイス及び／または格納デバイスが使用されている大きなプロバイダネットワークにおいて、コンポーネントのある部分集合におけるハードウェア及び／またはソフトウェア障害の可能性は、実施されているサービスの設計時に対応される必要がある。図１９は、少なくともいくつかの実施形態による、ノードチェーンのノードのうちの１つにおける障害発生時に、分散トランザクションの完了を簡易化するために実行され得る例示的動作を示す。３つの格納ノード１９３２Ａ、１９３２Ｂ、１９３２Ｃは、同一の論理エクステントＥ１のそれぞれのレプリカ１９０２Ａ、１９０２Ｂ、１９０２Ｃを格納するように示される。最初にレプリカ１９０２Ａがマスタレプリカとして指定され、一方１９０２Ｂ、１９０２Ｃは非マスタレプリカとして指定される。

任意の所定の分散トランザクションのために生成された格納ノードチェーンは一般に、トランザクションに関わるエクステントのマスタレプリカが格納される格納ノードを含み得る。このようなノードは、これらのエクステントのマスタレプリカが当該ノードに格納されることに関して、「マスタノード」または「リーダノード」とも称され得る。所定のノードチェーンメンバーにおいて物理ページに対して行われる変更は、マスタノードから他のレプリカの間に伝播され得る。従って、少なくともいくつかの実施形態において、前述のメッセージ（例えばＴｘ準備、Ｔｘコミット、Ｔｘアボート）は一般に、トランザクションに関わるエクステントのマスタノードへ送信され得る。

描かれた実施形態において、マスタノード１９３２Ａは、インテントレコード１９１５と、ページロック１９１０と、トランザクションステートレコード１９０５とを、Ｅ１のレプリカグループのメンバーが格納される他の格納ノードもアクセス可能な永続性共有レポジトリ１９８０に格納し得る。少なくともいくつかの実施形態において、分散トランザクションメッセージフローに参加する各ノードチェーンメンバー（図１６のノード１６３２Ａ、１６３２Ｂ、１６３２Ｃと、図１７のノード１６３２Ａ、１６３２Ｂ等）は、Ｔｘ準備、Ｔｘコミット、またはＴｘアボートメッセージがノードチェーンメンバーから送信された時に、分散トランザクションのステートに関する各ノードチェーンメンバーの局所的見解を示すトランザクションレコード１９０５を格納し得る。例えば、局所的ページ変更に関するコミット分析が変更は受諾可能であることを示し、かつ局所的ページを変更するインテントレコードが格納された場合、トランザクションステートレコードは、トランザクション（コーディネータにより選択され、Ｔｘ準備メッセージに含まれる一意的識別子により特定される）が、ノードチェーンメンバーの観点からすると準備完了ステートにあることを示す。決定者ノードは、トランザクション全体をコミットすると決定すると、ステートをコミット済みに設定したトランザクションレコードを保存し得る。描かれた実施形態において、非決定者ノードがＴｘコミットメッセージを受信すると、トランザクションのステート（前は準備完了であったステート）は、コミット済みに変更され得る。チェーンのいずれかのノードがトランザクションをアボートすると決定した場合、ステートがアボート済みに設定されたトランザクションステートレコードが、レポジトリ１９８０に格納され得る。任意のノードチェーンメンバーがＴｘアボートメッセージを受信すると、ステートをアボート済みに設定するようにトランザクションステートレコードは変更され得る。Ｔｘクリーンアップメッセージに関する論述において前述されるように、少なくともいくつかの実施形態において、所定の格納ノードの観点からトランザクションは完了したことに伴うメッセージ発信後、トランザクションステートレコード１９０５はある時間当該格納ノードにおいて保持され得る。これは、異なる実施形態において、例えばメッセージ損失による障害状態からの復旧を手伝うため、デバッグのため、監査のため等、様々な目的のために行われ得る。いくつかの実施形態において、所定のトランザクションに関してＴｘクリーンアップメッセージが受信されると、トランザクションステートレコードは、削除または記録保管され得る。

永続性ステートレポジトリ１９８０が使用され得ることで、トランザクションが完了する前（例えば、所定のトランザクションに関するＴｘ準備、Ｔｘコミット、Ｔｘアボート、またはマスタが送信する責任のあるメッセージ全てが、その意図する受信者に無事に受信される前）にマスタノードに障害が起こったとしても、フェイルオーバーノードがトランザクション関連動作を引き継ぐことが可能である。例えば、「１」と表示された矢印により示されるように、マスタノード１９３２Ａ（エクステントＥ１に関する）は、当該マスタノードが時間Ｔ１にレポジトリ１９８０内のＴｘ準備メッセージを受信した所定のトランザクションＴｘ１に関して、トランザクションステートレコード１９０５と、ページロック１９１０の開示と、インテントレコード１９１５とを書き込み得る。対応するＴｘコミットまたはＴｘアボートメッセージを受信する前に、「Ｘ」という印と「２」と表示された文により示されるように、ノード１９３２に障害が起こり得る。複製ステート管理プロトコルに従って、例えばレプリカ１９０２Ｂを新たなマスタとして指定することにより、ノード１９３２ＢがエクステントＥ１に関する新たなマスタノードとして選択され得る（表示「３」により示される）。いくつかの実施形態において、新たなマスタを選ぶのに、コンセンサスベースポリシーが使用され得る。ノード１９３２Ａに対し（ノード１９３２Ａの障害の前に）ＴｘコミットまたはＴｘアボートを送信したであろうノードチェーンメンバーは、エクステントＥ１に関するマスタの役割がノード１９３２Ｂへ委譲されたことを代わりに検出し、そのためＴｘコミットまたはＴｘアボートを代わりに１９３２Ｂへ送信し得る。インテントレコード、ロック、及びトランザクションステートレコードは全て永続性レポジトリ１９８０に格納されるため、ノード１９３２Ｂは、レポジトリ１９８０からＴｘ１に関する要求されるトランザクション情報を読み出し、ノード１９３２Ａが実行していたであろうトランザクション関連タスクを簡単に実行することが可能であり得る。少なくともいくつかの実施形態において、永続性レポジトリ１９８０は、レプリカ間に変更を伝播する、論理タイムスタンプを読み出し及び書き込みに対応付ける等の目的のために使用される複製ステート管理システムのコンポーネントとして実装され得る。

図２０は、少なくともいくつかの実施形態による、ファイルシステム格納サービスにおいて分散トランザクションを調整するために実行され得る動作の態様を例示するフロー図である。構成要素２００１に示されるように、変更を伴うファイルストア動作要求が、例えばメタデータノードにおいてアクセスノードから、または別のメタデータノードから受信され得る。要求の分析は、要求を遂行するために、例えば異なるエクステント及び／または異なる格納ノードにおける、複数ページ（メタデータ、データ、またはその両方を含む）が必要か否かを明らかにし得る。構成要素２００４にて検出されるように、単一ページのみを変更する場合、前述のものと同様の読み出し‐変更‐書き込みシーケンスが開始され得る（構成要素２００７）。

複数ページに対し変更または書き込みを行う必要がある場合（同様に構成要素２００４にて検出）、コーディネータノードを選択し特定することで（構成要素２０１０）、分散トランザクションが開始され得る。異なる実施形態において、コーディネータを選択するために、様々な技術が使用され得る。少なくとも一実施形態において、トランザクションに関わる参加ノードのうちの１つ、例えば対象ページのうちの１つのページのマスタレプリカが格納される格納ノード、またはトランザクションの影響を受けるメタデータを生成し管理する責任を担うメタデータノードのうちの１つが、選択され得る。いくつかの実施形態において、格納サブシステム、メタデータサブシステム、またはアクセスサブシステムのノードの集合が、事前にコーディネータ候補として指定され、当該候補から特定のノードが選択され得る。

コーディネータは、トランザクションを完了するために必要な様々な要素の情報を収集し得る（構成要素２０１３）。このような情報は、例えば、変更する全てのページのリストと、対応する書き込みペイロード（書き込むバイトのコンテンツ）のリストとを含み、描かれた実施形態において生成され得る。コーディネータはまた、例えばデッドロック回避機構を使用して、トランザクションのためにページレベルコミット分析が実行されるべき順序（ゆえにロックが確保されるべき順序）も決定し得る。いくつかの実施形態において、例えば、デッドロック回避機構を使用することは、全ての分散トランザクションに適用される無撞着並び替え方法論を使用して対象ページの識別子を並び替えることを含み、これにより、任意の２ページ上でロックが確保される順序は、１つのトランザクションから別のトランザクションにおいて変化しない。描かれた実施形態において、コーディネータは、例えば対象となるページを有する全てのエクステントの（現在の）マスタ格納ノードを特定し、コミット分析が実行されるべき順序に特定したマスタ格納ノードを配置することにより、トランザクションの格納ノードチェーンを構成し得る。少なくとも一実施形態において、コーディネータはまた、一意的トランザクション識別子（例えばランダムに生成されたストリングを組み込む汎用一意識別子すなわちＵＵＩＤ）を生成する責任も担い得る。前述の条件付き書き込み技術に関して論述されたもの等の読み出し論理タイムスタンプ（ＲＬＴ）または動作順序番号がＩ／Ｏ動作において利用可能ないくつかの実施形態において、コーディネータはまた、対象ページ全てを読み出し、読み出しに対応付けられたＲＬＴを特定し得る（構成要素２０１６）。コーディネータはそれから、ノードチェーンと、書き込みペイロードと、ＲＬＴとを示すＴｘ準備メッセージを構成し、チェーンの第１ノードに対しＴｘ準備メッセージを送信し得る（構成要素２０１９）。

少なくともいくつかの実施形態において、コーディネータはそれから、選択されたタイムアウト時間の後に終了するように設定されたタイマーを開始し、自身のＴｘ準備メッセージに対する応答を待ち得る。タイムアウト時間内に応答が受信されなかった場合（構成要素２０２３にて検出）、いくつかの実施形態において、構成要素２００１のファイルストア動作を要求したクライアントに対し、動作の結果が不明であることを示す応答が提供され得る（構成要素２０３５）。少なくとも一実施形態において、例えばチェーンの第１ノードがまだアクセス可能であればその第１ノードに対し、またはその第１ノードの代替ノードが検出または設定可能であればその代替ノードに対し、別のＴｘ準備メッセージを送信することで、トランザクションステート回復動作が開始され得る。

タイムアウト時間内にＴｘコミットメッセージがコーディネータにおいて受信された場合（構成要素２０２６にて特定）、これはトランザクションの個々のページ変更が全て無事に実行されたことを示し得る。従って、いくつかの実施形態において、コーディネータは、動作を要求したクライアントに対し、要求動作は成功したという開示を送信し得る（構成要素２０２９）。少なくとも一実施形態において、Ｔｘクリーンアップメッセージが、チェーンノードに対し、例えばＴｘコミットの受信者に対し非同期的に、送信され得る。そのため、ノードチェーンメンバーにおいてコミット済みトランザクションのトランザクションステートを保持する任意のリソースが解放され得る。前述のように、Ｔｘクリーンアップメッセージは、コーディネータにより、またはチェーンの第１メンバー等のその他の選択されたチェーンメンバーにより、送信され得る。

Ｔｘアボートメッセージがコーディネータにおいて受信された場合（同様に構成要素２０２６にて検出）、コーディネータは、いくつかの実施形態において、要求された動作は失敗したという開示をクライアントに対し任意で送信し得る（構成要素２０３２）。いくつかの実施形態において、Ｔｘクリーンアップメッセージは、コーディネータまたはチェーンのその他のメンバーにより、アボートされたトランザクションに参加していたチェーンメンバーに対しても送信され得る。いくつかの実施態様において、チェーンメンバーのうちのいずれかによりトランザクションはアボートされ得るため、チェーンメンバーの部分集合のみがアボートが起こる前にトランザクションステートレコードを格納しており、ゆえにチェーンメンバーの部分集合のみに対しＴｘクリーンアップメッセージが送信され得る。別の実施態様において、Ｔｘクリーンアップメッセージは単純にチェーンのノード全てに対し送信され、そしてＴｘクリーンアップメッセージ内で特定されるトランザクションのトランザクションステートを何も格納していないこれらノードは、Ｔｘクリーンアップメッセージを無視し得る。

図２１は、少なくともいくつかの実施形態による、格納サービスのノードにおいてトランザクション準備（Ｔｘ準備）メッセージを受信したことに応じて実行され得る動作の態様を例示するフロー図である。コーディネータにより構成されたノードチェーンのメンバーＣＭ、例えばトランザクションの一環として変更するページを有するエクステントのうちの１つのエクステントのマスタレプリカを格納するノードは、その他のノードから（例えば一般的に、コーディネータから、またはチェーンのある非決定者メンバーから）Ｔｘ準備メッセージを受信し得る（構成要素２１０１）。Ｔｘ準備メッセージは、トランザクションの提案ページ変更のリストにおいて、ＣＭにマスタレプリカが格納される親エクステントを有するページＰに対する１つまたは複数の提案ページレベル変更を示し得る。ＣＭは、例えばＴｘ準備メッセージ内でページＰに関して示される読み出し論理タイムスタンプが取得されて以来ページＰが変更されたか否かを、書き込みログバッファ（図１４に示されるバッファと同様）において調査することにより、ＣＭの観点から変更が受諾可能／コミット可能か否かを判定し得る。いくつかの事例において、ＣＭに格納されている同一ページに対する、または異なるページに対する、複数のページレベル変更がＴｘ準備メッセージにおいて示され、そして全てのこのような変更は受諾可能性に関して調査され得る。

構成要素２１０７において判定されるように、局所的ページレベル変更がコミット可能である場合、ＣＭが決定者（ノードチェーンの最後のメンバー）であるか否かによって、異なる動作が行われ得る。ＣＭが決定者である場合（構成要素２１１０にて検出）、局所ページ（複数可）に対する変更が開始され、そしてトランザクションがコミット済みステートであることを示すトランザクションレコードが、描かれた実施形態において永続性格納領域に格納され得る（構成要素２１１３）。決定者ノードはそれから、ノードチェーンの他のメンバーに対し、Ｔｘコミットメッセージの伝播を開始し得る（構成要素２１１６）。いくつかの実施形態において、Ｔｘコミットメッセージは、例えば同じトランザクションに関してＴｘ準備メッセージが送信された順序とは逆の順序で、順次伝播され得る。別の実施形態において、Ｔｘコミットメッセージは、並行して送信され得る。

局所的ページレベル変更がコミット可能であり、かつＣＭが決定者ノードではない場合（同様に構成要素２１０７と２１１０にて特定）、描かれた実施形態において、ＣＭは、（ａ）インテントレコード（残りのノードチェーンメンバーも自身の局所的変更がコミット可能であると判定した場合、ＣＭは自身の局所的変更を実行する意図があることを示す）を格納し、（ｂ）ＣＭの対象局所的ページをロックし（例えば分散トランザクション全体がコミット／アボートされるまでこれらのページに対するいずれの書き込みも防止するため）、（ｃ）トランザクションが準備完了ステートであることを示すトランザクションステートレコードを格納し得る（構成要素２１１９）。ＣＭはそれからＴｘ準備メッセージを、チェーン内の次のノードへ転送し得る（構成要素２１２２）。

ローカルページレベル変更がコミット不可能である場合（同様に構成要素２１０７にて検出）、例えばＴｘ準備メッセージ内に示されるページＰのＲＬＴが取得された後にページＰが書き込まれた場合、逐次一貫性セマンティックに対応するために、トランザクション全体はアボートされる必要があり得る。従って、ＣＭ（非決定者ノードまたは決定者ノードであり得る）は、トランザクションがアボートされたという開示を格納し得る（構成要素２１２５）。いくつかの実施態様において、トランザクションはアボート済みステートであることを示すトランザクションステートレコードが格納され得る。他の実施態様において、ダミーまたは「無演算」書き込みレコードが、ローカル書き込みログバッファ（図１４のバッファ１４５０と同様）に格納され得る。このようなダミー書き込みは、アボート済みステートを示すステートレコードと同じ効果を有し得る。すなわち、ある理由で（例えば誤メッセージまたは遅延メッセージを受信した結果として）ＣＭにおいてトランザクションの再試行が試みられた場合、再試行は失敗することとなる。ＣＭは、Ｔｘ準備メッセージを既に送信したチェーン内の他のノードに対し（もしそのようなノードが存在すれば）、及び／またはコーディネータに対し、Ｔｘアボートメッセージの伝播を開始し得る（構成要素２１２８）。

図２２は、少なくともいくつかの実施形態による、格納サービスのノードにおいてトランザクションコミット（Ｔｘコミット）メッセージを受信したことに応じて実行され得る動作の態様を例示するフロー図である。構成要素２２０１において示されるように、トランザクション用のＴｘ準備メッセージにおいてトランザクションコーディネータにより示されたノードチェーンメンバーＣＭは、Ｔｘコミットメッセージを受信し得る。一般にＴｘコミットメッセージは（少なくとも通常の動作条件の下）、ＣＭが自身の局所的ページレベルコミット分析を実行して、トランザクションが準備完了ステートであることを示すトランザクションレコードを格納した後のある時点に、受信され得る。Ｔｘコミットメッセージを受信したことに応じて、ＣＭは局所的対象ページに対し実際の変更を開始し（構成要素２１０４）、トランザクションが現在コミット済みステートであることを示すようにトランザクションステートレコードを変更し得る。いくつかの実施形態において、エクステントＥのデータ耐久性要件により、局所的ページ書き込みが完了したとみなされ得る前に、複数のエクステントレプリカが変更される必要があり得る。いくつかのこのようなシナリオにおいて、ＣＭは、ページ変更の開始後、必要なだけのレプリカの更新が完了するまで、トランザクションレコードを変更することを待ち得る。

ＣＭはそれから対象ページ（複数可）に対し維持していたロック（複数可）を解除し得る（構成要素２２０７）。少なくともいくつかの実施形態において、ＣＭがトランザクションのＴｘ準備メッセージに応じて格納していたインテントレコードが、この時点で削除され得る（構成要素２２１０）。前述のように、いくつかの実施形態において、Ｔｘコミットメッセージは、Ｔｘ準備メッセージとは逆の順序でチェーンメンバー間に順次伝播され、一方他の実施形態においては、並行伝播が使用され得る、あるいは順次伝播と並行伝播のある組み合わせが使用され得る。順次伝播が使用されている場合、またはチェーンのうちのいくつかのノードがＴｘコミットメッセージをまだ受信していないことをＣＭが判断可能な場合（例えばＣＭが受信したＴｘコミットメッセージ内の開示に基づいて）、ＣＭはチェーン内の選択されたノードに対し、またはコーディネータに対し、Ｔｘコミットメッセージを転送し得る（構成要素２２１３）。いくつかの実施形態において、重複Ｔｘコミットメッセージは無視され得る。例えば、所定のノードまたはコーディネータがトランザクションＴｘ１のＴｘコミットメッセージを受信し、Ｔｘ１はコミット済みのものとして既に記録されている場合、この新たなＴｘコミットメッセージは無視され得る。いくつかのこのような実施形態において、トランザクションを完了するのにかかる合計時間を短縮するために、Ｔｘコミットメッセージには、例えばＴｘコミットメッセージを受信した各ノードがチェーンの他のＮ個のノードに対しＴｘコミットメッセージを転送し得る非順次伝播機構が使用され得る。

図２３は、少なくともいくつかの実施形態による、格納サービスのノードにおいてトランザクションアボート（Ｔｘアボート）メッセージを受信したことに応じて実行され得る動作の態様を例示するフロー図である。構成要素２３０１に示されるように、Ｔｘアボートメッセージが、チェーンメンバーＣＭにおいて受信され得る。Ｔｘコミットメッセージと同様に、一般にＴｘアボートメッセージは（少なくとも通常の動作条件の下）、ＣＭが自身の局所的ページレベルコミット分析を実行して、トランザクションが準備完了ステートであることを示すトランザクションレコードを格納した後のある時点に、受信され得る。

Ｔｘアボートメッセージを受信したことに応じて、ＣＭは対象ページ（複数可）に対し維持していたロック（複数可）を解除し得る（構成要素２３０４）。少なくともいくつかの実施形態において、ＣＭがトランザクションのＴｘ準備メッセージに応じて格納していたインテントレコードが、この時点で削除され得る（構成要素２３０７）。Ｔｘコミットメッセージの場合のように、異なる実施態様において、Ｔｘアボートメッセージには、順次、並行、またはハイブリッド（すなわち順次と並行のある組み合わせ）伝播のいずれかが採用され得る。いくつかの実施形態において、Ｔｘアボートメッセージは、例えばＴｘ準備メッセージとは逆の順序でチェーンメンバー間に順次伝播され得る。順次伝播が使用されている場合、または前にＴｘ準備メッセージを送信したチェーンのうちのいくつかのノードがＴｘアボートメッセージをまだ受信していないことをＣＭが判断可能な場合（例えばＣＭが受信したＴｘアボートメッセージ内の開示に基づいて）、ＣＭはチェーン内の選択されたノードに対し、またはコーディネータに対し、Ｔｘアボートメッセージを転送し得る（構成要素２３１０）。いくつかの実施形態において、重複Ｔｘコミットメッセージの時のように、重複Ｔｘアボートメッセージは無視され得る。例えば、所定のノードまたはコーディネータがトランザクションＴｘ１のＴｘアボートメッセージを受信し、Ｔｘ１はアボート済みのものとして既に記録されている場合、この新たなＴｘアボートメッセージは無視され得る。いくつかのこのような実施形態において、トランザクションをアボートするのにかかる合計時間を短縮するために、Ｔｘアボートメッセージには、例えばＴｘアボートメッセージを受信した各ノードがチェーンの他のＮ個のノードに対しＴｘアボートメッセージを転送し得る非順次伝播機構が使用され得る。

エクステント予約超過モデルを使用するオンデマンドページ割り当て
数多くの格納システムにおいて、パフォーマンス目標は、時に格納領域効率性目標と潜在的に矛盾し得る。例えば、一般に、管理されているデータ量に対し比較的に小さいメタデータ量（論理ブロック対物理ページマッピングを含む構造等）を維持することは、様々な種類のファイルストア動作の迅速化に役立ち得る。メタデータが大きくなりすぎた場合、アクセスノードのメタデータキャッシュにおけるキャッシュヒット率は落ち、その結果、同じ数のクライアント要求に対応するために、アクセスサブシステムとメタデータサブシステム間においてより多くのインタラクションが必要となり得る。少なくともいくつかのメタデータは論理ブロックごとに保持され得るため、パフォーマンスの観点からすると、大きな論理ブロック（例えば４メガバイトまたは１６メガバイトの論理ブロック）を有することは、小さい論理ブロックを有するよりも良いということが示唆される。しかしながら、論理ブロックに対する第１書き込みが要求された時に論理ブロック全体の物理ページが割り当てられる場合、格納領域使用効率は準最適なものとなり得る。例えば、論理ブロックサイズが４ＭＢである（従って、論理ブロック全体に十分な格納領域が１度に割り当てられる場合、最小４ＭＢの物理格納領域が任意の所定ファイルに割り当てられる）シナリオを検討すると、所定のディレクトリまたはファイルシステム内のファイルに格納されるデータ平均量は、およそ３２ＫＢである。このようなシナリオにおいては、大量の物理格納領域が無駄になる。しかしながら、論理ブロックサイズが平均ファイルサイズ近くに設定された場合、結果的に、大きなファイルに対し非常に大量のメタデータが必要となり得るため、大きなファイルに対してだけでなく、ファイル格納サービス全体に対する動作が遅くなる可能性がある。

異なる実施形態において、格納領域効率性とパフォーマンス間のトレードオフに対処するために、多数の技術が使用され得る。一技術において、エクステントに予約超過モデルが使用され、所定の論理ブロック内の物理ページは、１度にまとめてではなくオンデマンドでのみ割り当てられ得る（すなわち論理ブロックサイズがＸキロバイトに設定され、かつ論理ブロックに対する第１書き込みのペイロードが（Ｘ−Ｙ）キロバイトのみである場合、Ｘ−Ｙキロバイトを格納するのに必要なページのみが、第１書き込みに応じて割り当てられ得る。）予約超過モデルの論述の後に説明される別の技術においては、所定のファイルストアオブジェクト内に異なるサイズの論理ブロックが採用され、そのためオブジェクトのストライプのうち少なくともいくつかのストライプのサイズは、他のストライプのサイズとは異なり得る。前述のように様々な実施形態（エクステントの予約超過及び／または可変論理ブロックサイズの使用が行われる実施形態も含む）におけるデータ耐久性のためにエクステントが複製され得るが、エクステント複製技術は、本明細書において論述される論理ブロック対ページマッピングとエクステント予約超過とに無関係であるとみなされ得ることに留意されたい。従って、エクステントレプリカは、予約超過エクステントに関して、または可変サイズストライプに関して、本明細書において詳細に論述されないものとする。説明を簡潔にするために、エクステント予約超過管理技術の論述の大部分に関して、及び可変サイズストライプまたは可変サイズ論理ブロックに使用される技術の論述に関して、論理エクステントは、単一物理エクステントを含むように仮定され得る。

図２４は、少なくともいくつかの実施形態による、分散格納サービスにおける予約超過の格納エクステントの例を示す。描かれた実施形態において、所定のファイルストアオブジェクト（ファイル２４００Ａ、２４００Ｂ、２４００Ｃ等）の論理ブロックは全て同じサイズであり、所定の論理ブロックに割り当てられた全ての物理ページは単一エクステントの一部である。描かれた実施形態において、所定のエクステント内の物理ページも一般に、当該エクステントの他の物理ページと同じサイズであり得る。従って、一例示的実施態様において、エクステントは１６ギガバイト分の３２ＫＢ物理ページを含み、一方論理ブロックは４メガバイトを含み得る。少なくともいくつかの実施形態において、エクステント、論理ブロック、及び／または物理ページのサイズは、それぞれの構成パラメータを使用して設定され得る。

示されるように、同一ファイルの異なる論理ブロックは、少なくともいくつかの事例において、異なるエクステントにマッピングされ、その結果、論理ブロックはストライプの均等物とみなされ得る。ファイル２４００ＡはＬＢ（論理ブロック）２４０２Ａ、２４０２Ｂを含む。ＬＢ２４０２Ａは、エクステントＥ２４３４Ａの複数の物理ページ（ＰＰ）２４１０Ａにオンデマンドでマッピングされる。同様に、エクステントＥ２４３４Ｂにおける複数の物理ページ２４１０Ｂは、オンデマンドでＬＢ２４０２Ｂに割り当てられる。エクステントＥ２４３４Ａにおいて、複数のページ２４１０Ａは、オンデマンドでファイル２４００ＢのＬＢ２４０２Ｌ、並びにファイル２４００ＣのＬＢ２４０２Ｐに割り当てられる。エクステントＥ２４３４Ｂにおいて、複数のページ２４１０Ｂは、オンデマンドでファイル２４００ＢのＬＢ２４２０Ｋ、及びファイル２４００ＣのＬＢ２４０２Ｑに割り当てられる。オンデマンド割り当て技術は、描かれた実施形態において、以下のように実施され得る。特定の論理ブロックに対する書き込み要求が受信される度に、ファイル内の開始オフセットと、書き込みペイロードのサイズ（書き込むまたは変更するバイト数）を使用して、任意の新たな物理ページを割り当てるか否かを決定し、割り当てる場合には、どれだけの新たな物理ページを割り当てる必要があるかを決定し得る。（いくつかの書き込み要求は、前に割り当てられたページを対象とし得るため、任意の新たなページを割り当てられる必要があり得ない）。例えば論理ブロックの一部が書き込まれる可能性のある物理ページの集合全体を一度に割り当てる代わりに、書き込みペイロードを収容するのに必要な数の新たな物理ページのみが割り当てられ得る。以下の例を検討する。ＬＢ２４０２Ａのサイズは４メガバイトであり、ＰＰ２４１０Ａのサイズは３２ＫＢである。ＬＢ２４０２Ａに対する２８ＫＢの書き込みペイロードを有する第１書き込みが受信される。この前に、当例示的シナリオにおいて、ＬＢ２４０２Ａに対し物理格納領域は何も割り当てられていない。格納サービスは、１つのＰＰ２４１０Ａのみが当該第１書き込みに必要であると判断する（単一３２ＫＢページ内に２８ＫＢは収容可能であるため）。その結果、エクステントＥ２４３４Ａ内の１つのＰＰ２４１０Ａのみが割り当てられる。とはいえ、描かれた実施形態において所定の論理ブロックに対する全てのページは同一のエクステント内から割り当てられる必要があるため、４ＭＢのＬＢ２４０２Ａ全体が最終的にはエクステントＥ２４３４Ａ内に格納される必要がある。

一般に、少なくともいくつかの実施形態において、論理ブロックの何割が結局書き込まれるのか予測することは簡単ではなく、例えばいくつかのスパースファイルは、幅広く異なる論理オフセットに小さなデータ領域を含み得る。描かれた実施形態において、格納領域使用効率性を向上するために、エクステントＥ２４３４Ａ、Ｅ２４３４Ｂそれぞれに予約超過が実施され得る。エクステントが、エクステントの現行サイズ内に完全に物理的に収容可能な論理ブロックよりも多い論理ブロックに対する書き込み要求を受諾するように構成される場合、エクステントは予約超過であるとみなされ得る。例えば、全ての論理ブロック内の完全なオフセット範囲が、何らかの方法で同時に書き込まれる場合、エクステントは拡張される必要があり得る（または別のエクステントが使用される必要があり得る）。従って、予約超過パラメータ２４５５Ａに示されるように、Ｎ個の論理ブロックがエクステントＥ２４３４Ａにマッピングされ、各論理ブロックは最大Ｍ個のそれぞれＹキロバイトの物理ページにマッピングされることが可能である。エクステントＥ２４３４Ａの現行サイズはＸキロバイトであり、Ｘは（Ｎ^*Ｍ^*Ｙ）より小さい。描かれた実施形態において、エクステントの実サイズ（Ｘ）に対する可能性のある格納超過量（（Ｎ^*Ｍ^*Ｙ）−Ｘ）の割合に等しい予約超過因数ＯＦ１がエクステントＥ２４３４Ａに適用される。同様の予約超過パラメータ２４５５ＢがエクステントＥ２４３４Ｂに適用される。Ｅ２４３４Ｂは、Ｚキロバイトまでのみ現在格納可能であるが、Ｑ個のそれぞれＲキロバイトの物理ページに各自マッピング可能なＰ個の論理ブロックに対する書き込み要求を受諾するように構成される。Ｚは（Ｐ^*Ｑ^*Ｒ）より小さく、Ｅ２４３４Ｂの予約超過因数ＯＦ２は、ゆえに（（Ｐ^*Ｑ^*Ｒ）−Ｚ）／Ｚである。いくつかの実施形態において、様々のエクステントが、異なる予約超過因数で構成され得る。一実施形態において、全てのエクステントに対し、均一予約超過因数が使用され得る。後述のように、いくつかの実施形態において、予約超過因数及び／または予約超過因数に対応付けられた空き格納領域閾値は、少なくともいくつかのエクステントに関して、例えばファイルシステム使用または動作の収集メトリクスに基づいて、継時的に変更可能である。各エクステントレベルでの予約超過管理に関して本明細書において説明されるものと同様の技術が、同様にまたは代わりに、様々な実施形態における他のレベルでの予約超過に適用され得る。例えば、格納サブシステムノードはそのエクステントの予約超過に基づいて予約超過が実施され得る、個々の格納デバイスに対し予約超過が実施され得る、等が挙げられる。

図２５は、少なくともいくつかの実施形態による、オンデマンドの物理ページレベル割り当て及びエクステント予約超過を実施する分散マルチテナント格納サービスのサブシステム間のインタラクションを例示する。描かれた実施形態において、示されるように、メタデータエクステント（Ｅ２５３４Ａ等）とデータエクステント（Ｅ２５３４Ｂ等）の両方に、予約超過が実行され得る。矢印２５０１により示されるように、アクセスノード２５１２からの特定の論理ブロック（ＬＢ）に対する第１書き込み要求が、メタデータノード２５２２において受信され得る。書き込み要求は、サイズ「ＷＳ」の書き込みペイロードを含み、例えばファイル２４００に対するクライアントの書き込み要求に応じてアクセスノード２５１２において生成され得た。

書き込み要求２５０１が受信された時点では、論理ブロック自体のメタデータは作成され得なかった。例えば、書き込みは単純に、ファイル２４００がオープンになった後の当ファイルに対する第１書き込みであり得る。描かれた実施形態において、メタデータノード２５２２は、まずＬＢメタデータを生成し、書き込み得る。要求２５５４は、例えばＬＢのメタデータを格納するために格納ノード２５３２Ａへ送信され得る。格納ノードは、ブロック２５５８により示されるように、予約超過メタデータエクステントＥ２５３４Ａからページを割り当て、メタデータノード２５２２により生成されたメタデータを格納し得る。使用する特定のメタデータエクステントは、メタデータノード２５２２、格納ノード２５３２Ａのいずれかにより、または異なる実施形態における格納サービスの別の配置コンポーネントにより、選択され得る。当該選択は、変更されるファイルの名前、様々なエクステントにおける利用可能な空き格納領域の量等、様々な要素に基づいて行われ得る。

描かれた実施形態において、メタデータノード２５２２も、ＷＳバイトの書き込みペイロードを格納するために、どれだけの新たな物理データページを割り当てるか決定し得る。ＷＳバイトを収容するために適切な数の物理ページの要求２５６２が、少なくともいくつかの実施形態において、ＬＢメタデータに使用される格納ノードとは異なる格納ノード２５３２Ｂへ送信され得る。描かれた実施形態において、格納ノード２５３２Ｂは、予約超過データエクステント２５３４Ｂにおける要求された数の物理ページ（少なくともいくつかの事例において、論理ブロックのアドレス範囲全体が一度に書き込まれた場合に必要となるであろうページ数よりも少なくあり得る）を割り当て得る。描かれた実施形態において、物理ページの識別は、エクステント２５３４Ａにおいて格納されるＬＢメタデータ内に格納され得る。例えば、格納ノード２５３４Ｂは、エクステント２５３４Ｂ内のデータページのアドレスをメタデータノード２５２２へ送信し、メタデータノード２５２２は、ＬＢメタデータ内に当該アドレスを書き込むように格納ノード２５３２Ａに対し要求を送り得る。いくつかの実施形態において、メタデータページが割り当てられる前に、データページが割り当てられ得る。これにより、例えばメタデータページの割り当ては、データページアドレスの書き込みと組み合わせ可能となり、追加メッセージを必要としない。一実施形態において、書き込みペイロードはデータページの割り当て要求２５６２と共に、メタデータノード２５２２により格納ノード２５３２Ｂへ送信され得る。この場合、ＷＳバイトの書き込みは、データページの割り当てと組み合わされ、追加メッセージを必要としない。少なくともいくつかの実施形態において、データページ（複数可）が第１書き込み要求２５０１に割り当てられた後、データを格納する予定の好適な格納ノード（２５３２Ｂ）の識別がアクセスノード２５１２に提供され、そしてアクセスノード２５１２は当該格納ノードに対し書き込みペイロードを送り得る。

少なくともいくつかの実施形態において、先に述べたように、予約超過モデルの使用により、所定のエクステントが格納するように指定されるコンテンツを有する論理ブロック全てに対して、十分な格納領域を所定のエクステントが提供しきれない状況に陥り得る。従って、いくつかの実施形態において、予約超過エクステントは時々拡張される必要があり得る、あるいはエクステントコンテンツはその元のエクステントからより大きなエクステントへ移動またはコピーされる必要があり得る。いくつかの実施形態において、エクステントレベルのデータコピーまたはエクステント拡張に対応した場合に生じ得る同期遅延を回避するために、空き格納領域閾値が予約超過エクステントに割り当てられ得る。このような実施形態において、空き格納領域閾値が破られると、非同期エクステント拡張動作、またはエクステントコンテンツの非同期転送が実行され得る。異なるエクステントは、自身に与えられた格納作業負荷の特性に応じて、異なる割合で拡大し得る。少なくともいくつかのエクステントに関して、最大エクステントサイズが定義され得る（例えば使用されている特定の格納デバイスの容量に基づいて）。その結果、特定のエクステントがこのような最大エクステントサイズに達すると、当該エクステントはもはや予約超過とはみなされ得ず、そして格納サービスはこのような最大サイズのエクステントに対処するために、さらに拡大可能なエクステントに使用される論理とは異なる論理を採用し得る。いくつかの実施形態において、選択されたエクステントは、拡大する他のエクステントに場所を空けるために、別の格納ノードまたは別の格納デバイスへ積極的に移動され得る。このような積極的な移動は、いくつかの実施態様において、進行中のクライアントが要求した動作の乱れを最小限にするために、バックグラウンドタスクとして実行され得る。異なる実施形態において、他のエクステントに場所を空けるためにどのエクステントを積極的に移動するか選択するのに、多数の異なるルール、ポリシー、またはヒューリスティックが使用され得る。例えば一実施形態において、積極的移動には、大部分の容量が既に使用されているエクステントに優先して、大部分の容量が使用されていないエクステントが選ばれ得る。別の実施形態においては、逆の手法が使用され得る。例えば、指定された最大サイズに既に到達したエクステント（または指定された最大サイズにもう少しで到達するエクステント）は、まだ大幅に拡大可能なエクステントに優先して、移動され得る。同様に、エクステントが移動される先の対象格納デバイスまたは格納ノードも、様々な実施形態において、設定可能ポリシーに基づいて選択され得る。一実施形態において、エクステントは、絶対に必要な時のみ移動され得る（例えば積極的移動は実施され得ない）。

図２６ａは、少なくともいくつかの実施形態による、空き格納領域閾値が指定されたエクステントを例示する。一方図２６ｂは、少なくともいくつかの実施形態による、空き格納領域閾値の侵害に起因するエクステントの拡張を例示する。図２６ａにおいて示されるように、予約超過エクステントＥ２６３４Ａに対する空き格納領域閾値集合が設定され得ることにより、拡張を引き起す前に、最大限度２６５０であるＭ個の物理ページがエクステント内で割り当てられ得る。エクステント２６３４Ａの割り当て済みページの数ＫがＭより小さい（すなわち未割り当てページＬの数が空き閾値限度を超えている）限り、図２５において例示される書き込み要求に応じて、新たなページがオンデマンドで割り当てられ得る。Ｍ番目のページが割り当てられた場合／時、図２６ｂの矢印２６５５により示されるように、元のエクステント２６３４Ａのコンテンツを、より大きなまたは拡張されたエクステント２６３４Ｂへ非同期でコピーすることが開始され得る。示されるように、拡張されたエクステント２６３４Ｂの最大割り当て限度（Ｎページ）は、元のエクステント２６３４Ａの割り当て限度であるＭページよりも大きくあり得る。いくつかの実施形態において、少なくともいくつかのエクステントでは、ページをコピーすることなく拡張を行うことが可能であり得る。例えば、所定の予約超過エクステントが、所望する拡張を収容するのに十分な格納領域を有する格納デバイス上に配置される場合、エクステントのサイズは、格納デバイス内で増大可能である。別の実施形態において、元のエクステントのコンテンツは、別の格納デバイスへ、潜在的に別の格納ノードにおいて、コピーされる必要があり得る。従って、一実施態様において、拡張されたエクステント２６３４Ｂは、元のエクステント２６３４Ａとは異なる物理格納デバイスを使用し得る。少なくともいくつかの実施態様において、例えば１０ＧＢのＮ１エクステントが作成され得る、２０ＧＢのＮ２エクステントが作成され得る等、いくつかの異なるサイズのエクステントが格納サービスにて作成され得る。このような実施形態において、エクステントの拡張は、例えば１０ＧＢのエクステントからのページを、既存の２０ＧＢのエクステントへコピーすることを伴い得る。本明細書において使用される用語「エクステント拡張」は、例えばエクステントの現場拡張を伴う動作、または１つの格納デバイスから別の格納デバイスへエクステントコンテンツの転送を伴う動作といった、これらの種類の動作のうちのいずれかを一般的に指す意図があり、これらの動作は、予約超過エクステントにおいて空き格納領域閾値が侵害された時に追加データまたはメタデータコンテンツを格納する能力につながる。従って、いくつかの実施形態において、エクステントの拡張は実質的には、エクステントに使用されている格納デバイスを別の格納デバイスに置き換えることにより、元のデバイスと同じ格納ノードにおいて、または別の格納ノードにおいて、行われ得る。いくつかの実施形態において、拡張前のエクステントを指すためにエクステント識別子Ｅ１が使用され、かつ拡張後に別の格納デバイスが使用される場合、拡張後に別のエクステント識別子Ｅ２が使用され得る。別の実施形態においては、拡張後に同じ識別子が使用され得る。

図２７は、少なくともいくつかの実施形態による、エクステント予約超過に対応する格納サービスにおいてオンデマンドの物理ページ割り当てを実施するために実行され得る動作の態様を例示するフロー図である。構成要素２７０１において示されるように、分散マルチテナントファイル格納サービスの複数の格納サブシステムノードにおいて、複数の物理エクステントが構成され得る。いくつかの実施形態において、１つまたは複数の異なるサイズを有する複数のエクステントは、例えばプロバイダネットワークのリソースの集合において格納サービスが開始された時に、事前構成され得る。別の実施形態においては、エクステントの集合は、新たなファイルストア（例えばファイルシステム）が初期化された時に、構成され得る。いくつかの実施形態において、各エクステントは、選択された複数の物理ページのために十分な格納領域を有し、各ページは、データまたはメタデータの論理ブロックのコンテンツを格納するために使用可能な複数のバイトを有する。例えば、一実施形態において、エクステント集合のそれぞれのエクステントは特定のＳＳＤまたは回転ディスクベースの格納デバイス上に８ギガバイトの格納領域を有し、エクステントに格納するコンテンツを有するオブジェクトにおいて使用されるデフォルトの論理ブロックサイズは４ＭＢであり、そして物理ページサイズは３２ＫＢに設定され得る。このパラメータ集合では、各論理ブロックは１２８個までの物理ページを有することが可能であり、そして各エクステントはおよそ２０００個までの充満論理ブロック（少なくとも４ＭＢのデータが実際に書き込まれ、論理ブロック内に未書き込みオフセット範囲が存在しないブロック）を格納することが可能である。少なくともいくつかのファイルシステムプロトコル書き込みはファイルまたはメタデータ構造内のランダムなオフセットを対象とし得るため、一般に、論理ブロック内のオフセットの範囲全てがデータ(またはメタデータ）を含み得るとは限らない場合があり得る。描かれた実施形態において、所定の論理ブロックのコンテンツは、所定のエクステント内に含まれ得る。例えば、所定の論理ブロックがマッピングされる全ての物理ページは、同じエクステントの一部である必要があり得る。

論理ブロック内に未書き込みギャップの可能性があるため、所定のエクステントに対して、ブロックがデータ／メタデータで充満にされた場合に収容可能な論理ブロック数よりも多い論理ブロックが割り当て可能であることに従って、エクステントの少なくともある部分集合に対して、予約超過パラメータの集合が決定され得る（構成要素２７０４）。所定のエクステントに対するパラメータは、例えば、予約超過因数（例えばエクステントにマッピングされた論理ブロックに対しどれだけの追加格納領域が潜在的に必要となり得るかを示す測定）、エクステント拡張等の様々な動作が引き起こされる１つまたは複数の閾値（前述の空き格納領域閾値等）、閾値が満たされた時に現行のエクステントのコンテンツがコピー／移動されるべき所望の格納デバイスまたはエクステント等を示し得る。

ファイルまたはメタデータ構造に対する第１書き込み等、ファイルストアオブジェクトの論理ブロックＬＢ１に対する特定の書き込み要求に応じて、論理ブロックのコンテンツを格納するために、利用可能なエクステントのうち特定のエクステントＥ１が選択され得る（構成要素２７０７）。例えば、Ｅ１は、ＬＢ１のＭ個までのページを含む合計Ｐ１個までのページ（マルチテナント環境におけるいくつかの異なるファイルストアオブジェクトの一部であり得る）を格納することが可能であり得る。少なくともいくつかのシナリオにおいて、Ｅ１は選択された時点で予約超過であり得る。例えば、Ｅ１にマッピングされた論理ブロック（少なくとも一部はデータまたはメタデータで充満した状態であり得ない）の合計サイズが、Ｅ１の現行サイズを超え得る。異なる実施形態において、Ｅ１は、格納領域の空き領域の割合、ファイルストアオブジェクトを格納するのに所望する格納デバイスの種類（ＳＳＤまたは回転ディスクベース）等、様々な基準に基づいて、選択され得る。第１書き込みに対しＥ１内の１つまたは複数のページが割り当てられ、そして第１書き込み要求のペイロードがそこに書き込まれ得る（構成要素２７１０）。割り当てられたページの合計サイズはペイロードを収容するのに十分であり得ると同時に、割り当てられたページの合計サイズは、少なくともいくつかの事例において、論理ブロックＬＢ１のサイズよりも小さくあり得る（例えばペイロードサイズがＬＢ１のサイズよりも小さい場合）。少なくともいくつかの実施形態において、通常の動作条件下では、第１書き込みを実行することがＥ１の空き格納領域制約を侵害しない場合にのみ、Ｅ１は第１書き込み用に選択され得る。

Ｅ１に対するサイズＷＳの書き込みペイロードを伴う後続の書き込み要求が受信され得る（構成要素２７１３）。後続書き込み要求は、ＬＢ１またはその他のＥ１にマッピングされた論理ブロックを対象とし得る。書き込みペイロードＷＳを収容するのに必要なだけの物理ページを割り当てても、Ｅ１に設定された空き格納領域閾値を侵害しない場合（構成要素２７１６にて検出）、必要な数の物理ページが割り当てられ、そして要求される書き込みが実行され得る（構成要素２７１９）。Ｅ１の空き格納領域閾値が侵害される場合（同様に構成要素２７１６にて検出）、描かれた実施形態において、１つの同期動作及び１つの非同期動作が開始され得る。書き込み要求に対して同期的に、例えば書き込み要求に応答する際いかなる長い遅延も避けるために、Ｅ１内で１つまたは複数の追加ページが割り当てられる。非同期的に、図２６ｂに関して前述されたようなエクステント拡張動作が開始され得る。エクステント拡張は、例えば、元の格納デバイスにおけるＥ１関連メタデータを変更することによるＥ１の現場拡張を伴い得る、あるいは、Ｅ１のコンテンツのうち少なくともいくつかを、より大きなエクステントが構成され得るその他の格納デバイス（及び／または他の格納ノード）へ転送することを伴い得る。少なくともいくつかの実施形態において、Ｅ１は、ファイルストアに対応付けられたデータ耐久性ポリシーに従って構成されるレプリカグループのうちの１つのエクステントレプリカ（マスタレプリカ等）であり、当該ファイルストアのＬＢ１はブロックであり、かつＥ１において実行される当該ファイルストアの書き込みは、前述のような複製技術（例えば消失訂正符号、完全複製等）に従う１つまたは複数の追加レプリカへ伝播され得ることに留意されたい。エクステントに予約超過が実施され、かつ所定のブロック内のページがオンデマンドで割り当てられる少なくともいくつかの実施形態において、所定のエクステントまたは論理ブロック内のページのサイズは異なり、及び／または所定ファイルまたはメタデータ構造内の論理ブロックのサイズは異なり得る。

動的オンデマンドのページレベル格納割り当てには、同じ論理ブロックの部分を切り離す副次的影響があり得る。例えば、所定の論理ブロックに割り当てられたページは、少なくともいくつかの事例において、使用されている格納デバイス（複数可）上で隣接し得ない。いくつかの実施形態において、ファイルストア動作の様々な特性を経時的に監視して、例えば予約超過の程度、並びに物理格納デバイス上の所定論理ブロックのページ配置方法を含むエクステント予約超過の実施方法を最適化することが可能であり得る。図２８は、少なくともいくつかの実施形態による、エクステント予約超過パラメータを動的に変更するために実行され得る動作の態様を例示するフロー図である。構成要素２８０１に示されるように、エクステントＥ１、Ｅ２等のある集合に対する予約超過パラメータの初期集合に従って、時間帯Ｔ１に、データ及び／またはメタデータに対し物理ページが割り当てられ得る。

Ｔ１の間に、予約超過エクステントを使用して実行されているファイルストア動作において、多数の異なるメトリクスが収集され得る（構成要素２８０４）。例えばランダムアクセス対順次アクセスの読み出し及び／または書き込みの割合を特定するために、ファイルアクセスパターンが分析され得る。ファイルサイズに関して（例えば平均または中間ファイルサイズに関して、及びファイルサイズが経時的に変化する傾向に関して）、ファイル間のギャップ（例えば論理ブロックが投入されるエクステント）に関して、及び／または様々な種類の動作の応答時間及び処理量に関して、統計が収集され得る。いくつかの実施形態において、かつ特定の種類の動作に関して、ファイル名からファイルアクセスの蓋然的パターンを推測することは実行可能であり得る。例えば、電子メールを格納するのに使用されるファイルは、ファイル名の拡張子に基づいて識別可能であり、特定の方法でアクセスされることが見込まれ得る、データベースログまたはウェブサーバログに使用されるファイルは、名前により識別可能であり、特徴的なアクセスパターンを有し得る、等が挙げられる。格納領域使用に関するこのような情報及びメトリクスは、例えば機械学習技術に従う格納サービスの最適化コンポーネントにおいて分析され、予約超過パラメータのいずれかを変更することは得策であり得るか否か、またはいくつかの論理ブロックの物理ページを統合すべきか否かが判断される。予約超過閾値の変更により格納領域の使用レベルは改善され得ると判断されると（構成要素２８０７）、閾値は適宜変更され（構成要素２８１０）、そして変更されたパラメータを適用した時の新たなメトリクスの集合が収集され得る。例えば、一実施形態において、ファイルシステムＦＳ１の予約超過パラメータ設定は、最初は控えめに設定され得る。例えば予約超過因数はたった１０％に設定され得る。後ほど、ＦＳ１内のオブジェクトに関する格納領域使用メトリクス及びアドレス範囲ギャップが分析された後に、許容予約超過レベルは、例えば２０％まで引き上げられ得る。論理ブロックのある集合の物理ページを再配置することで、ファイルストアパフォーマンス（例えば順次読み出し／書き込みに関する）が改善され得ると判断される場合、選択された物理ページのコンテンツは再配置され得る（構成要素２８１３）（例えば、所定ブロックのコンテンツを保持するために隣接する領域を割り当て、当該ブロックのコンテンツをその元の非隣接位置から隣接位置へとコピーすることにより）。少なくともいくつかの実施形態において、このような再配置は一般に、受信Ｉ／Ｏ要求に対し非同期的に実行され得るため、読み出し／書き込み要求を発するクライアントは、最適化動作に起因する遅延を体感しない。様々な実施形態において、例えばいくつかのエクステントを、現在使用されているものよりも速い格納デバイス（ＳＳＤ等）または遅い格納デバイスに移動させるといった他の種類の最適化も、同様の分析に基づいて開始され得る。

可変ストライプサイズ
いくつかの実施形態において、前述のメタデータサイズと格納領域効率性の間のトレードオフのために、別の手法が取られ得る。いくつかの実施形態において、当技術を採用することで、エクステントは予約超過を実施する必要がなく、そして例えば第１書き込みが所定の論理ブロックを対象とする時に、所定の論理ブロックに必要となる可能性のある格納領域全てが予め取得され得る。しかしながら、所定の格納オブジェクト内の論理ブロック（前述のように、エクステント、格納デバイス、または格納ノードにわたってファイルデータ及び／またはメタデータをストライピングする単位を表し得る）は、全てが同じサイズであり得るとは限らない。いくつかのこのような実施形態において、論理ブロックサイズ、ゆえに１度に割り当てられる格納領域量は、ファイル内の論理オフセットに応じて増大し得る。第１ブロックに割り当てられる比較的小さい量の格納領域から始まり、後続のブロックに対しますます大きな格納領域が割り当てられ得る。従って、小さい格納領域と大きい格納領域の両方により、オブジェクトサイズに比例して増大する量のメタデータを作成することなく、小さいファイルと大きいファイルの両方を実施することが可能になり得る。

図２９は、少なくともいくつかの実施形態による、可変ストライプサイズを使用して格納されるコンテンツを有するファイルストアオブジェクトの例を示す。図４を参照して論述されたように、ファイルストアオブジェクトの異なる論理ブロックは一般に（必ずしもではないが）、それぞれの格納ノードの異なる格納デバイスにおける異なるエクステントにマッピングされ、そのため論理ブロックはストライプの均等物とみなされ得ることを想起されたい。様々な実施形態において、可変ストライプサイズを使用して様々なメタデータ構造も実施され得るが、ファイル２９００は、格納オブジェクトの例として選択される。ファイル２９００は、４つのストライプすなわち論理ブロックＬＢ２９０２Ａ、２９０２Ｂ、２９０２Ｃ、２９０２Ｄを含むことが示される。論理ブロックのある部分集合は同じサイズであり得るが、論理ブロック２９０２のうちの少なくともいくつかは、他の論理ブロックのうちの少なくともいくつかとはサイズが異なり得る。

図２９において、固定サイズページを有するエクステントと可変サイズのページを有するエクステントの２種類のエクステントが示される。エクステント２９３４Ａは、物理ページ２９１０を有し、それぞれのページのサイズはＳ１ＫＢである。エクステント２９３４Ｂのページ２９１０ＢのサイズはそれぞれＳ２ＫＢであり、一方エクステント２９３４ＣのページのサイズはＳ３ＫＢである。描かれた実施形態において、Ｓ１、Ｓ２、Ｓ３はお互いに異なり、例えばＳ１はＳ２より小さく、Ｓ２はＳ３より小さくあり得る。先に述べたように、少なくとも固定ページサイズを有するエクステントに関して、物理ページは、いくつかの実施形態における対応最小Ｉ／Ｏ単位を表し得る。従って、描かれた実施形態において、エクステント２９３４Ｂ、２９３４Ｃよりも小さい読み出し及び書き込みをエクステント２９３４Ａにおいて対応することが可能であり得る。エクステント２９３４Ｄは可変サイズページに対応する。すなわち、任意の量の物理格納領域（ある特定された最小量及び最大量を有する）がエクステント２９３４Ｄ内において１度に割り当てられ得る。これに対して、エクステント２９３４Ａ、２９３４Ｂ、２９３４Ｃ内においては、格納領域がそれぞれの複数のページサイズに割り当てられ得る。少なくともいくつかの実施形態において、ページサイズの離散集合、または単一ページサイズのみが対応され得る。

少なくともいくつかの実施形態において、ＬＢ２９０２に対する第１書き込みに応じて、ストライプ全体の物理格納領域（第１書き込みの書き込みペイロードに必要な物理格納領域よりも多くあり得る）が、選択されたエクステントから割り当てられ得る。従って、例えば、エクステント２９３４Ａの１つまたは複数のページ２９１０ＡがＬＢ２９０２Ａに使用され、エクステント２９３４Ｂの１つまたは複数のページ２９１０ＢがＬＢ２９０２Ｂに使用され得る。同様に、ＬＢ２９０２Ｃに対し１つまたは複数のページ２９１０Ｃがエクステント２９３４Ｃから割り当てられ、エクステント２９３４Ｄから１つまたは複数のページがＬＢ２９０２Ｄに割り当てられ得る。いくつかの実施形態において、任意の所定の論理ブロックすなわちストライプは、物理格納領域の１つの連続領域にマッピングされ、一方別の実施形態において、所定の論理ブロックに割り当てられた物理格納領域は、少なくともいくつかの事例では格納デバイスのアドレス空間内において非連続であり得る。比較的小さいストライプサイズが使用される場合、例えば小さなファイルでもファイルの最初のいくつかのストライプに関して、複数のエクステントにわたってストライピングされ得る。このように、単一の大きいストライプサイズが使用されていたら達成されなかったであろうストライピングのパフォーマンス利益が獲得される。

一般に、描かれた実施形態において、特定のオフセットと書き込みペイロードサイズを有する書き込み要求が受信されると、当該書き込みは追加格納領域を割り当てる必要があるか否かに関して判定が行われ得る（オフセットとペイロードサイズに基づいて）。このような判定は、少なくともいくつかの実施形態において、格納サービスのメタデータノードにおいて行われ得る。格納領域を割り当てる必要がない場合、ペイロードに割り当てる隣接物理格納領域の量（通常であって必ずではない）が決定され得る。少なくともいくつかの実施形態において、割り当てられる格納領域の量は、書き込みオフセットに依存し得る。（ファイルの存在の経過を通したストライプサイズ決定パターンの例、及びストライプサイズを決定する時に考慮され得るいくつかの種類の要素の例については、より詳しく後述される）。所望する量の格納領域を割り当てるのに使用可能なエクステントを有する１つまたは複数の格納ノードが、特定され得る。例えば、１キロバイトのストライプに対し格納領域を割り当てる場合、格納サービスは、１ＫＢのページを有し、かつストライプの書き込みを収容するのに十分な空き格納領域を有するエクステントを特定することを試み得る。選択されたエクステントにおける最小ページサイズは、ストライプすなわち論理ブロックのサイズと等しくある必要はないことに留意されたい。例えば、ストライプサイズは３ＫＢであるが、４ＫＢのページに対応するエクステントが使用可能、あるいは２ＫＢのページまたは１ＫＢのページに対応する別のエクステントが使用可能である。所望のストライプサイズに対する物理格納領域が取得された後に、書き込みペイロード内に示された変更が開始され得る。エクステントが複製されるいくつかの実施形態において、例えば、マスタレプリカが格納される格納ノードから変更が取り仕切られ、当該マスタノードから、または当該マスタノードにより、非マスタレプリカに対し変更が伝播され得る。

いくつかの実施形態において、所定ファイルまたはメタデータ構造内のストライプサイズは、オフセットに応じて予測可能な様式で変更し得る。図３０は、少なくともいくつかの実施形態による、ファイルストアオブジェクトに使用され得るストライプサイズ決定シーケンスの例を示す。ストライプサイズシーケンス３０１０Ａにおいて、ファイルストアオブジェクトの最初の９個の論理ブロックのサイズが、それぞれ例えば１ＫＢ、１ＫＢ、２ＫＢ、２ＫＢ、４ＫＢ、４ＫＢ、８ＫＢ、１６ＫＢ、３２ＫＢに設定され得る。このようなパターンは、例えば、小さいと見込まれるファイルまたはメタデータ構造、または比較的ゆっくりと増大することが見込まれるファイルまたはメタデータ構造に使用され得る。例えばある高い確率でたくさんの順次書き込みが見込まれる別のファイルに対しては、最初の４個のブロックのサイズがそれぞれ１ＭＢ、４ＭＢ、１６ＭＢ、６４ＭＢに設定される別のストライプサイズシーケンス３０１０Ｂが使用され得る。従って、ストライプサイズの離散集合が実施される実施態様においてでさえ、１つのファイルＦ１に使用されるストライプサイズは、別のファイルＦ２に使用されるストライプサイズのうちのいずれかとは異なり得る。いくつかの実施形態において、使用するストライプサイズシーケンス３０１０のうちの少なくともいくつかは、格納サブシステムの構成パラメータとして特定され得る。いくつかの事例において、ファイルが大きくなると、小さいストライプをより大きなストライプに統合すると便利であり得る（メタデータパフォーマンス及びデータアクセスパフォーマンスの両方にとって）。

図３１は、少なくともいくつかの実施形態による、ファイルストアオブジェクトに対しストライプサイズ決定３１７０及び／または統合決定３１７２を行うためにメタデータサブシステムにおいて考慮され得る要素例を示す。描かれた実施形態において、メタデータサブシステムノード１２２は、ファイル及びメタデータ構造を含む様々なファイルストアオブジェクトのストライプ／論理ブロックサイズを決定する責任と、物理ページ及び／または論理ブロックを結合または統合するべきかどうか、並びにするべき時を決定する責任とを担い得る。格納領域を割り当てるファイルストアオブジェクトの次の部分に使用するストライプサイズを決定する時、メタデータノード１１２は、オブジェクトの現行サイズ３１０１と、書き込み要求ペイロードサイズ３１０３とを考慮し得る。一実施態様において、例えば、ファイルストアオブジェクトに割り当てられる第１ストライプのサイズは、オブジェクトに対する第１書き込みの書き込みペイロードに基づき得る。例えば、第１書き込みのペイロードが３．５メガバイトである場合、４メガバイトのストライプサイズが選択され、一方第１書き込みが２メガバイト以下である場合には、２メガバイトのストライプサイズが選択され得る。いくつかの実施形態において、顧客の要求でファイルまたはディレクトリが作成されると、例えばオブジェクトは主に、順次書き込み及び読み出し、ランダム書き込み及び読み出し、またはある順次とランダムの混合アクセスのために使用される予定であることを示すヒント３１０５が格納サービスに提供され、そしてこのようなヒントはストライプ／論理ブロックサイズを選択するのに使用され得る。異なるサイズの書き込み及び／または読み出しで達成された平均応答時間等、ファイルシステムパフォーマンスのメトリクス３１１０も、いくつかの実施形態における論理ブロックサイズの選択に、及び／または前に作成されたストライプのコンテンツをより大きなストライプに結合する統合動作のスケジューリングに、影響し得る。

いくつかのシナリオにおいて、前述のように、ファイルまたはディレクトリの名前（またはファイル拡張子等の名前の一部）により、ファイルまたはディレクトリのコンテンツの見込まれる拡大またはアクセス様式に関するある案内が提供され得る。例えば、電子メールサーバ、ウェブサーバ、データベース管理システム、アプリケーションサーバ等のいくつかのアプリケーションは、その機能の様々な部分に、周知のファイル拡張子及び／またはディレクトリ階層を使用するため、メタデータノード１１２の最適化コンポーネントは、このようなファイル／ディレクトリ名３１１５に基づいて、より知的にストライプサイズを選択することが可能になり得る。少なくとも一実施形態において、メタデータノード１１２は、アクセスパターン（例えばランダム対順次、読み出しパーセント対書き込みパーセント、読み出しサイズ分散、書き込みサイズ分散）を特定し、ストライプサイズを適宜選び得る。オブジェクト存続時間（例えば所定のファイルストアにおいてファイル作成から削除までの間の平均経過時間）の測定３１２５は、いくつかの実施形態において、ストライプサイズの決定を行うのに役立ち得る。例えば、所定のディレクトリ内のほとんどのファイルは作成後Ｘ時間内に削除されると見込まれる場合、それらのストライプサイズに関する決定は、さほど長期的に影響し得ない。いくつかの実施形態において、エクステント領域使用メトリクス３１３０及び／または格納ノードリソース使用メトリクス３１３５（使用されている格納ノードのＣＰＵ、メモリ、またはネットワーク使用レベル等）もまた、ストライプサイズの決定に関与し得る。一実施形態において、１つまたは複数のトリガー基準に基づいて、例えばファイルまたはメタデータ構造が閾値サイズを超えた場合／時に、またはファイルに対する頻繁順次アクセスが検出された場合／時に、所定のファイルまたはメタデータ構造の小さいストライプは、より大きなストライプに結合され得る。このような結合動作は、使用されるエクステントの特性により（例えば異なるエクステントにおいて対応される特定のページサイズにより）、１つの格納デバイスから別の格納デバイスへ、または１つのエクステントから別のエクステントへ、データ／メタデータを移動またはコピーすることを伴い得る。少なくともいくつかの実施形態において、継時的に格納サービスにて行われるストライプサイズ決定及び／または統合決定を改善するために、機械学習技術が採用され得る。このような機械学習手法の一環として、全体的なファイルストアパフォーマンス及び／またはコストに対する、図３１に例示される様々な要素の相対的影響が分析され得る。

図３２は、少なくともいくつかの実施形態による、可変ストライプサイズを使用してストライピングを実施するために実行され得る動作の態様を例示するフロー図である。例えば分散マルチテナント格納サービスのメタデータノード１１２において、ファイルストアオブジェクト内の書き込みオフセットと書き込みペイロードとを示す書き込み要求が、受信または生成され得る（構成要素３２０１）。いくつかの事例において、ファイル書き込み等の顧客が発したファイルシステムＡＰＩ呼び出しに応じて、書き込み要求はアクセスノード１２２において生成され得る。一方他の事例においては、メタデータノード自体が、ある新たなメタデータを格納すること、または既存のメタデータを変更することを決定し得る。対象オブジェクトの書き込みオフセット、書き込みペイロード、及び既存メタデータ（もしあれば）の分析に基づいて、書き込みを実行するために追加格納領域を割り当てる決定がなされ得る（構成要素３２０４）。（先に述べたように、全て予め書き込まれたコンテンツの変更から成るいくつかの書き込みは、追加格納領域を必要とし得ない。）

例えばファイルストアオブジェクトに使用されているオフセットベースのストライプサイズ決定シーケンス（図３０に示されるシーケンスと同様のもの）に基づいて、及び／またはオブジェクトのサイズ、検出されたアクセスパターン等の図３１に示される要素のある組み合わせに基づいて、ファイルストアオブジェクトの次の新たなストライプすなわち論理ブロックのサイズが決定され得る（構成要素３２０７）。そして選択されたサイズのストライプの少なくとも１つのレプリカを格納するために使用する特定のエクステント、格納ノード、及び／または格納デバイスが特定され得る（構成要素３２１０）。図２９に関連して論述されたように、少なくともいくつかの実施形態において、所定のエクステントは特定の物理ページサイズを使用するように構成され、その結果、全てのエクステントが所定の論理ブロックサイズに対し格納領域を割り当てるのに適し得るとは限らない。従って、エクステントはそのページのサイズに基づいて選択され得る。いくつかのシナリオにおいて、対応エクステントの物理ページサイズの離散集合に対応する論理ブロックサイズの離散集合のみが、許可され得る。可変ページサイズに対応するように構成されるエクステント（図２９のエクステント２９１１等）が、いくつかの実施形態において利用可能であり、このようなエクステントは、様々なサイズの論理ブロック／ストライプに格納領域を割り当てるために選択され得る。いくつかの実施形態において、新たな論理ブロックすなわちストライプに対し格納領域が割り当てられると、エクステントのレプリカグループのために、複数の格納ノード（例えばいくつかの可用性コンテナまたはデータセンタに分散されている）が特定され得る。

所望量の物理格納領域の割り当て要求は、少なくとも１つの選択された格納ノードへ送信され得る（構成要素３２１３）。格納ノードは、要求された物理格納領域、例えばストライプがコンテンツで一杯である場合、ストライプのコンテンツを格納するのに必要なだけのページを割り当て得る（構成要素３２１６）。そして書き込み要求内に示される変更が、開始または実行され得る（構成要素３２１９）。ファイルストアオブジェクトに対応付けられたデータ耐久性ポリシーによって、書き込み完了と見なすことができる前に、書き込みペイロードがいくつかの異なるレプリカへ伝播される必要があり得る。少なくともいくつかの実施形態において、オンデマンドのページ割り当て及び／または予約超過エクステントは、前述のような可変ストライプサイズ決定と組み合わせて使用可能であることに留意されたい。

オフセットベースの輻輳制御技術
データ集合の小部分に対する同時性の高いアクセスを行う顧客作業負荷は、分散ファイル格納サービスにおいてホットスポットを生じる可能性がある。例えば、ほぼ同時に複数のスレッドの実行を利用するファイルの複数順次読み出しを顧客が要求する場合、全てのスレッドは、最初にファイルの先頭近くの単一ストライプすなわち論理ブロックにアクセスすることになり得る。さらに、論理ブロックの相対的サイズと読み出しペイロード（顧客からの各読み出し要求において要求されているデータの量）によって、複数の読み出し要求は各スレッドから単一ストライプを対象とし得る。このようなシナリオにおいて、多数のクライアントがほぼ同時に同一論理ブロックから複数読み出しを要求する場合、個々のスレッドに対し乏しい全体処理量及び／または劣った応答時間とならないように、論理ブロックのアドレス範囲内に輻輳制御技術が実施され得る。いくつかの実施形態において、このような輻輳制御技術は、オフセットベースの優先度とＩ／Ｏ要求を対応付け得る。これは例えば、読み出し要求に与えられるスケジューリング優先度は、論理ブロック内の読み出しオフセットが大きい程、高くなり得る。

オフセット依存の輻輳制御技術の論述を動機付けるには、非優先度読み出し要求スケジューリングに起因し得る潜在的に問題のあるシナリオの例示が役立ち得る。図３３は、少なくともいくつかの実施形態による、格納サービスオブジェクトの論理ブロックを対象とする全ての読み出し要求に対し相互に等しい優先権が与えられるスケジューリング環境における、論理ブロックに対する複数同時読み出し要求の進捗の例示的タイムラインを示す。潜在的問題をより明らかに例示するために、例の様々なパラメータに極値が選択されている。選択されたパラメータには、常例的シナリオを代表する意図はない。

図３３において、経過時間は左から右へと増加する。およそ時間Ｔ０に、１００クライアントスレッドそれぞれが、エクステントＥ３３３４の２つの物理ページＰＰ１とＰＰ２に格納されるコンテンツ（例えばデータまたはメタデータ）を有する論理ブロック３３０２の順次読み出しを開始する。論理ブロック３３０２は、例えば、他の論理ブロック（図示せず）も含むファイルの第１論理ブロックを表し得る。例えば論理ブロック全体を読み出すのに、ＬＢ３３０２のコンテンツが１度に１ページ読まれることを想定すると、所定のクライアントはまずＰＰ１を読み出し、それからＰＰ２を読み出す必要がある。エクステントＥ３３３４は、エクステント処理能力３３０２に示されるように、毎秒Ｉ／Ｏ２５ページまで処理可能である。確実に所定の秒中に２５ページを超える読み出しが開始されることを許可しないように、当処理能力限度は、図示された例示的シナリオにおいて強調されたものとして仮定され得る。Ｉ／Ｏ優先度付けポリシー３３０１により示されるように、全ての読み出し要求は、均等な優先度を有するように処理される（優先度付けを使用しないのと同じ効果を有する）。これらのパラメータを所与として、タイムラインに沿った以下の時間、Ｔ０、Ｔ０＋１秒、Ｔ０＋２秒、Ｔ０＋３秒、Ｔ０＋４秒におけるクライアント要求のステートを検討する。

およそＴ０に、１００個の要求がページＰＰ１の読み出しを開始することを待っている。エクステント処理能力制約により、２５個の要求のみが、Ｔ０からＴ０＋１の間にＰＰ１の読み出しを開始する（及び終了する）ことを許可される。従って、Ｔ０＋１には、７５クライアントがまだＰＰ１を読み出しておらず、一方２５クライアントはＰＰ１の読み出しを完了している。しかしながら、全ての要求は均等な優先度で処理されるため、ＰＰ１の読み出しを完了した２５クライアントは、残りの７５クライアントがＰＰ１を読み出し終わるまで、ページＰＰ２へ進むことは不可能である場合が当然あり得る。従って、Ｔ０＋１にてより濃い角丸長方形で示される２５クライアントは、他の７５クライアントがＰＰ１の読み出しを完了するのを待ち得る。時間Ｔ０＋２に、さらに２５クライアントがＰＰ１の読み出しを完了済みであり得るが、こちらも残りの５０クライアントがＰＰ１を読み出し終わるまで待つ必要があり得る。時間Ｔ０＋３に、２５クライアントがまだＰＰ１を読み出しておらず、ＰＰ０を読み出した７５クライアントは、これらを待つように強制され得る。ＬＢ３３０２のページを対象とする全ての読み出し要求に対し均等優先度が割り当てられる例示的シナリオにおいて、１００クライアント全てが第１ページを読み出し終えたＴ０＋４にて初めて、クライアントのうちのいずれかがページＰＰ２へ進むことが許可される。

少なくともいくつかの実施形態において、より進捗しているクライアントに対しより高い優先度（または同等により低いコスト）を割り当てることにより、順次読み出しで達成される全体的パフォーマンスを改善することが可能であり得る。図３４は、少なくともいくつかの実施形態による、オフセットベースの輻輳制御ポリシーが使用されるスケジューリング環境における、格納サービスオブジェクトの論理ブロックに対する複数同時読み出し要求の進捗の例示的タイムラインを示す。論理ブロック３３０２は再度、毎秒Ｉ／Ｏ２５ページの処理能力を有するエクステントＥ３３３４における２つのページＰＰ１とＰＰ２とを有す。描かれた実施形態において、ＬＢ３３０２は、輻輳制御を実施するオフセットベースのＩ／Ｏ優先度付けポリシー３４０１を有する。ポリシーに従って、ＬＢ３３０２内のより大きいオフセットに対する読み出し要求は、より小さいオフセットに対する読み出し要求よりも、高い優先度が与えられる。

およそＴ０に、１００クライアントが自身の順次読み出し動作を開始する。Ｔ０＋１に、２５クライアントはページＰＰ１の読み出しを完了し、これら２５クライアントは今度は、残りの７５クライアントよりも大きいオフセットでの読み出しを要求する。オフセットベースの優先度付けポリシーに従って、ＰＰ１を読み出し終えた２５クライアントは、時間Ｔ０＋１に残りの７５クライアントよりも高い優先度を与えられる。従って、これら２５クライアントは今度は、ページＰＰ２の読み出しを開始し、一方他の７５クライアントは待機する。時間Ｔ０＋２に、２５クライアントはＬＢ３３０２全ての読み出しを終え、順次読み出されているファイルまたはメタデータ構造の次の論理ブロック（もしあれば）へ進むことができる。次の論理ブロックは（高い確率で）別の格納デバイスに格納され得るため、次の論理ブロックへ進むことは、Ｔ０＋２から１００クライアントの作業負荷が、均等優先度が使用されている場合の同一エクステントに尚も向けられる代わりに、２つの格納デバイスに分散され始め得ることを意味する。Ｔ０＋３に、さらに２５クライアントがＰＰ１の読み出しを終え、まだＰＰ１を読み出していない残りの５０クライアントよりも高い優先度を与えられる。Ｔ０＋４に、さらに２５クライアントが両ページの読み出しを終え、次の論理ブロックへ進むことができる。その一方、図３４のＴ０＋４に５０クライアントはまだページＰＰ１を読み出していない（これは、これら５０クライアントの観点からすると、図３３に示される均等優先度が全てのクライアントに適用されている場合に達成され得たＴ０＋４に１００クライアント全てがページＰＰ１の読み出しを終えるという結果よりも、悪い結果である）。従って、図３４に例示されるスキームにおいて、いくつかのクライアント要求は、他に対して幾分「不公平」に取り扱われ得る。不公平に関する別の例示として、クライアントＣ１、Ｃ２から時間Ｔｋ、（Ｔｋ＋デルタ）にＩ／Ｏ要求Ｒ１、Ｒ２をそれぞれ受信するシナリオを検討する。Ｒ１は論理ブロック内のオフセットＯ１を対象とし、Ｒ２は論理ブロック内のオフセットＯ２を対象とし、Ｏ２はＯ１より大きい。Ｒ１の後にＲ２が受信されたとしても、Ｒ２は、そのオフセットが大きいことに基づいてより高い優先度が割り当てられ、ゆえに図３４のスキームの下、Ｒ１よりも早くにスケジュールされ得る、及び／または完了され得る。いくつかの事例において、例えばＲ２が順次読み出しパターンの一部である場合、順次読み出しの集合全体は、オフセットベースの優先度付けの結果、Ｒ１がスケジュールされる前に完了し得る。しかしながら、この「不公平」にも関わらず、図３４のスキームは一般に、オフセットに関係なく全ての要求に均等優先度を適用する場合と比べて、様々なクライアント集合の順次読み出しが異なる格納デバイスにより早く分散される傾向にあるように、より早くＩ／Ｏ作業負荷並列処理へと導く傾向がある。アクセスされているファイルストアオブジェクトが異なる格納デバイスに複数のストライプを有するシナリオにおいて（これはほとんどのファイルストアオブジェクトの場合に見込まれる）、このようにオフセットベースの優先度付けを使用して格納デバイス間により均等に作業負荷を分散することは、順次動作の全体平均完了時間と全体処理量を改善するのに役立ち得る。数百または数千のクライアントを同時に対応するマルチテナント格納サービスのコンポーネントの観点からすると、特定のページ読み出し要求がランダム読み出しであるか、または順次読み出しシーケンスの一部であるかを記録することは必ずしも簡単（または効率的）とは限らないため、いくつかの実施形態において、オフセットベースの優先度付けは、読み出しがより大きな順次走査の一部であるか否かに関係なく、概してページレベル読み出しに使用され得る。少なくともいくつかの実施形態において、論理ブロック内のオフセットベースの優先度付けは、データ及び／またはメタデータに対する、順次読み出し、順次書き込み、ランダム読み出し、ランダム書き込みの動作の任意の組み合わせに使用され得る。

図３４に例示されるものと同様の原理に基づいた多数の異なるオフセットベースの輻輳制御技術が、異なる実施形態において採用され得る。図３５ａは、少なくともいくつかの実施形態による、格納サービスにおいてＩ／Ｏ要求をスケジューリングするために使用され得るトークンベースの輻輳制御機構の例を示す。図３５ｂは、少なくともいくつかの実施形態による、採用され得るオフセットベースのトークンコストポリシーの例を示す。一般的に、格納オブジェクト、データベーステーブル、データベースパーティション等の様々な種類のエンティティの作業負荷管理にトークンベース機構が使用され得る。分散ファイル格納サービスに関連して、このようなバケットが、ファイルの論理ブロックのため、メタデータ構造の論理ブロックのため、ファイル全体のため、及び／またはメタデータ構造全体のために様々な実施形態において保持され得る。簡潔な説明のために、トークン３５０１の単一バケット３５０８を使用する機構が図３５ａに例示される。しかしながら、いくつかの実施形態において、読み出し動作用に１つのバケット、書き込み動作用に別のバケットというように、複数のバケットの組み合わせが使用可能である。当該機構によれば、ファイルの論理ブロック等の特定の作業対象に対応付けられる輻輳制御目的のために構成されたバケット３５０８（例えば、少なくともいくつかの実施形態において、ソフトウェア輻輳制御モジュール内にデータ構造として実装され得る論理コンテナ）には、矢印３５０４Ａにより示されるように、バケット初期化中にトークン３５０１の初期集合が追加され得る。様々な実施形態において、初期保有数は、例えば、同時作業負荷レベルの予測、作業対象に対応付けられる引き当て動作限度、またはこのような要素のある組み合わせに基づいて、決定され得る。いくつかの実施形態において、一部の種類のバケットの初期保有数は、ゼロに設定され得る。いくつかの実施態様において、バケットの初期保有数は、当該バケットに設定された最大保有数に設定され得る。

描かれた実施形態において、新たなＩ／Ｏ要求３５２２（読み出し要求または書き込み要求等）が受信されると、例えば格納ノード１３２の輻輳制御サブコンポーネントにおいて、輻輳コントローラが、ある数Ｎ個のトークン（Ｎは１以上であり、実行内容または構成パラメータに依存する）がバケット３５０８に存在するか否かを特定するように試み得る。その数のトークンがバケットにおいて利用可能な場合、Ｉ／Ｏ要求３５２２は実行対象として直ちに受諾され、そしてバケットから当該トークンが消費または削除され得る（矢印３５０６）。そうでなく、描かれた実施形態において、Ｎ個のトークンが存在しない場合、要求される格納動作の実行は、十分なトークンが利用可能になるまで、先送りされ得る。所定のＩ／Ｏ要求に使い切られるトークン数は、Ｉ／Ｏ要求を受諾するための「コスト」と称され得る。

３５０４Ｂと表示された矢印により示されるように、バケット３５０８は、例えばバケットに対応付けられる補充率等の構成パラメータに基づいて、経時的に補充または再追加され得る。いくつかの実施態様において、トークン補充動作は消費動作と同時に起こり得る、または時間的に近接して行われ得る。例えば単一のソフトウェアルーチン内で、要求を許可することでＮ個のトークンが消費され、そして補充率及び前回バケットが補充されてから経過した時間に基づいてＭ個のトークンが追加され得る。いくつかの実施態様において、例えば一般的に短い時間間隔でより高い作業要求率を処理可能にするために、所定のバケットの補充率または補充トークン数が変更され得る。例えば構成パラメータを使用して、いくつかの実施形態においてバケットが保持可能なトークンの最大数、及び／またはトークンの最小数に対し、制限が設定され得る。様々な組み合わせの構成パラメータ設定を使用することで、異なる実施形態において、トークンバケットを使用する非常に高度な受付制御スキームが実施され得る。特に、後述されるように、異なるオフセットを対象とするＩ／Ｏ要求に対し異なるトークンコストを要求することにより、図３４の例と同様のオフセットベースの優先度付けが実施され得る。

一単純例示的シナリオにおいて、論理ブロックＬＢ１にて均等優先度の２５個の毎秒Ｉ／Ｏ要求（ＩＯＰＳ）という一定負荷に対応するために、バケット３５０８は、初期保有数２５トークン、最大許容保有数２５トークン、及び最小許容保有数ゼロトークンに設定され得る。Ｉ／Ｏ毎のコストは１トークンに設定され、補充率は毎秒２５トークンに設定され、そして４０ミリ秒毎に１度、（最大保有数限度を超えないという前提で）補充目的で１トークンが追加され得る。Ｉ／Ｏ要求３５２２が到着すると、要求ごとに１トークンが消費され得る。各秒均一に分散した２５ＩＯＰＳの定常作業負荷が適用される場合、補充率及び作業負荷到着率は釣り合い得る。いくつかの実施形態において、上記のバケットパラメータを前提とした場合、このような定常作業負荷は無期限に対応可能である。しかしながら、２５以上のＩ／Ｏ要求が所定の秒中に受信される場合、一部の要求は待機する必要があり、図３３に例示されるようなシナリオとなり得る。

オフセットに関係なくＩ／Ｏ要求毎のコストを１トークンに設定する代わりに、一実施形態においては、ファイル内のより大きいオフセットを対象とするＩ／Ｏ要求に求められるトークンよりも多くのトークンが、より小さいオフセットを対象とするＩ／Ｏ要求に求められ得る。このようなトークンコストポリシー３５７６の例が図３５ｂに示される。ポリシー３５７５によれば、論理ブロック内の０から６４ＫＢの間のオフセットを対象とするＩ／Ｏごとに１０トークンが要求され、６４ＫＢから２５６ＫＢの間のオフセットを対象とするＩ／Ｏに５トークンが要求され、そして２５６ＫＢより大きいオフセットを対象とするＩ／Ｏごとに１トークンが要求される。より小さいオフセットに対しより多くのトークンが要求されるため、小さいオフセットを対象とするＩ／Ｏは、所定のトークンバケット保有数及び補充率に関してブロックされる、または遅れが生じる可能性が高く、一方でより大きいオフセットを対象とするＩ／Ｏは一般に、より早くスケジュールされ得る。異なる実施形態においてオフセットからコストを計算するために、様々な異なる数学関数またはマッピングが選択され得る（例えばヒューリスティック、格納システムの機械学習コンポーネント、またはアドミニストレータにより選ばれた構成設定に基づく）。いくつかの実施形態において直線型オフセットベーストークンコストポリシー３５６１が使用され、一方他の実施形態において３５６２等の非直線型コストポリシーが使用され得る。様々な論理ブロック、ファイル、またはメタデータ構造に使用されているコストポリシー、補充率、及び他の輻輳制御パラメータは、例えば格納サービスから取得されるパフォーマンスメトリクスの分析に応じて、経時的に変更され得る。いくつかの実施形態において、所定のファイルストアオブジェクト内の異なる論理ブロックに対し異なるパラメータが使用され、及び／または異なるファイルストアオブジェクトに対し異なるパラメータが選択され得る。少なくともいくつかの実施形態において、同様のオフセットベースの輻輳制御技術が、論理ブロックレベルの代わりに、または論理ブロックレベルに加えて、ファイルストアオブジェクトレベルに適用され得る。例えば、ＹがＸより小さい場合、ファイル内のオフセットＹを対象とするＩ／Ｏに割り当てられる優先度より高い優先度が、オフセットＸを対象とするＩ／Ｏに割り当てられ得る。いくつかの実施態様においてトークンベース技術を使用する代わりに、論理ブロック内または格納オブジェクト内を対象とするＩ／Ｏ要求に異なる優先度を割り当てるために、いくつかの実施形態において他の可変コスト割り当て技術が使用され得る。例えば、一実施形態において、各Ｉ／Ｏ要求に数的コストが単純に割り当てられ、そして未処理のＩ／Ｏ要求は割り当てられたコストの逆の順序に処理され得る。

少なくとも一実施形態において、論理ブロックまたはファイルストアオブジェクト内の異なるオフセット範囲に対するＩ／Ｏ要求に対し、それぞれのキューが構成され得る。このような各キューは、そのキューの中のＩ／Ｏ要求のうちのいずれか１つが処理されるまでの対応遅延間隔を有し、小さいオフセットＩ／Ｏ要求に対し長い遅延が割り当てられ得る。図３６は、少なくともいくつかの実施形態による、格納サービスにおける輻輳制御のためのオフセットベース遅延の使用例を示す。描かれた実施形態において、４つのキュー３６０２Ａ、３６０２Ｂ、３６０２Ｃ、３６０２Ｄが示される。それぞれが、論理ブロックの特定のオフセット範囲内のＩ／Ｏ要求（要求Ｒ３６３１等、「Ｒ」から始まる表示により示される）に指定される。キュー３６０２Ａは、（例えばバイトで）０からＰ−１の間のオフセットに対するＩ／Ｏ要求に使用される。キュー３６０２Ｂは、オフセットＰから２Ｐ−１の間のオフセットに対するＩ／Ｏ要求に使用される。キュー３６０２Ｃは、２Ｐから４Ｐ−１の間のオフセットに対するＩ／Ｏ要求に使用される。キュー３６０２Ｄは、４Ｐより大きいオフセットに対するＩ／Ｏ要求に使用される。各キュー３６０２は、そのキュー内の行列する任意の２つのＩ／Ｏ要求の実施間に必ず経過する最小時間を示す、対応最小遅延を有する。キュー３６０２Ａ、３６０２Ｂ、３６０２Ｃ、３６０２Ｄの最小遅延が、それぞれ４ｄ、２ｄ、ｄ、０と示される。ｄは１秒に設定され、時間Ｔにおける様々なキューの保有要求は示される通りであり、そして少なくとも数秒の間は新規の要求は到着しないという例示的シナリオを検討する。キュー３６０２Ｄの要求はゼロ秒の最小遅延であるため、要求Ｒ３６３４が最初にスケジュールされ、Ｒ３６３８がこれに続き得る。それからキュー３６０２Ｃ内の要求が、各要求の完了から次の要求の開始までの間に１秒の遅延を入れてスケジュールされ得る。それからキュー３６０２Ｂの要求が、２秒の間隔を入れてスケジュールされ得る。これに、１対ずつの要求の間に４秒の遅延が入るキュー３６０２Ａの要求が続く。描かれた実施形態において、最小遅延は、Ｉ／Ｏ要求の行列遅延を増大させる。例えば、特定の要求Ｒ１は、Ｒ１の前に到着した同じオフセット範囲内の他の要求が存在するという単純な理由から、そのキューにおいてＫ秒待つ必要があり、そしてＲ１がキューの先頭に達した時にも、Ｒ１はそのキューに対応付けられた最小遅延時間を待つ必要があり得る。描かれた実施形態において、一般に、スケジュールされる要求間に遅延が設定されることで、これらの遅延中に到着する大きいオフセットの（ゆえに優先度の高い）要求が、より早く処理されることが可能になり得る。異なる実施形態において、輻輳制御のために、多種多様な簡潔なオフセットベースのキュー作成技術が使用され得る。例えば、一実施形態において、所定のキュー３６０２に対応付けられる遅延は、処理を待っている優先度の高い要求の数に依存し得る。一実施態様において、所定のＩ／Ｏ要求に使用される遅延は、単純にそのオフセットに定数を掛けることで計算され得る。

いくつかの実施形態において、オフセットベースの優先度付けを実施する機構として、エラーメッセージが使用され得る。特定のＩ／Ｏ要求Ｒ１が小さいオフセットのある他の要求（複数可）を対象とする場合、Ｒ１をキューの中に配置する、またはＲ１に使用するトークンをさらに要求する代わりに、エラーメッセージがＲ１を送ったクライアントに返され得る。そこでクライアントはＩ／Ｏを再試行し得る（クライアントがＩ／Ｏは必要であると尚も考えることを想定する）。再試行により生じる遅延は、前述のオフセットベースのキューにおける要求の挿入と、類似していると考えられ得る。

少なくともいくつかの実施形態において、論理ブロックが格納される格納デバイスは、優先度付けポリシーが施行される前に、閾値作業負荷レベルに到達する必要があり得る。例えば、図３５において、エクステントＥ３３３４は毎秒Ｉ／Ｏ２５ページの規定またはベースラインの処理能力を有し、その結果、描かれた実施形態において、優先度付けポリシーは、作業負荷が処理能力を超えた（または少なくとも処理能力に近づいた）時にのみ適用され得る。少なくともいくつかの実施形態において、優先度付けを引き起こす閾値自体は、変更可能なパラメータであり得る。例えば、様々な実施形態において、異なるエクステントに対し、異なる格納ノードに対し、異なる物理格納デバイスに対し、または同じエクステント内の異なる論理ブロックに対し、別個の閾値が適用され得る。このような閾値は、様々な要素に基づいて動的に変更され得る。一実施態様において、エクステントの全体作業負荷レベル（例えばある時間を通して取得された測定の統計分析に基づいて計算される）、エクステントが配置される格納デバイスまたは格納ノード、または閾値が適用される特定の論理ブロックでさえにも、少なくとも一部基づいて、閾値は変更され得る。閾値を調整するのに使用可能な他の要素には、例えば、論理ブロックに対するＩ／Ｏ要求を送るクライアント（複数可）の識別もしくは論理ブロックを含む格納サービスオブジェクトが作成されたクライアントの識別（例えば一部のクライアントは他のクライアントよりも重要であるとみなされ、従ってより高い閾値が割り当てられ得る）、１日の中の時間（例えば午後１１から午後６時までの間等、通常利用率の低い時間帯に閾値は高くなり得る）、またはファイルシステム、ディレクトリ、ファイル、ボリューム、もしくはエクステントを使用して実行される他の格納オブジェクトの名前が含まれ得る。

いくつかの実施形態において、ランダム性要素が輻輳制御技術に追加され得る。例えば、各オフセット範囲に対する固定の遅延を実施する代わりに、ランダム成分（ある選択された乱数生成器を使用して取得される）を含む遅延が使用され得る。トークンベースの輻輳制御スキームにおいて、所定のオフセット範囲を対象とするＩ／Ｏ要求の要件に、トークンの乱数が追加され得る。いくつかの事例において、このようなランダム化は、作業負荷分散を平準化するのに役立ち、例えば格納デバイスが十分に活用されていない状況になってしまい得る望ましくないエッジケースの確率を低減するのに役立ち得る。

少なくともいくつかの実施形態において、異なる輻輳制御ポリシーが、異なるカテゴリの格納動作に使用され得る。図３７は、少なくともいくつかの実施形態による、アクセスされている格納オブジェクトの種類、及び要求されるアクセスの様々な特徴によって決まり得る輻輳制御ポリシーの例を示す。テーブル３７８０に示されるように、輻輳制御パラメータ設定３７１０は、コンテンツの種類３７０２（例えばメタデータかデータか）、要求は読み出しか書き込みか（Ｉ／Ｏの種類の列３７０４）、及び／または要求は順次シーケンスの一部かランダムシーケンスの一部か（アクセスパターンの列３７０６）に基づいて変わり得る。Ｉ／Ｏペイロードサイズ（列３７０８）（例えば何バイトのデータ／メタデータが読み出される、または書き込まれるか）、及び／または対象オブジェクトの現行サイズ（列３７１０）に基づいて、異なる輻輳制御設定が同様にまたは代わりに使用され得る。

個別読み出しペイロードサイズが４ＫＢ未満であり、かつメタデータ構造がＳ１ＭＢより小さいメタデータ構造の順次読み出しに関して、描かれた実施形態において、直線型オフセットベースの優先度付けが輻輳制御に使用され得る。任意のサイズのランダムメタデータ書き込み動作は、均等の優先度を有するものとして処理される。１２８ＭＢより大きいサイズのファイルを対象とする、ペイロードサイズが６４ＫＢより大きい順次データ読み出しは、オフセットの関数として指数関数形崩壊型のオフセットベース優先度付けを使用する。説明を簡潔にするために、図３６から、輻輳制御ポリシーの様々な詳細（各優先度レベルに対応付けられたコスト、異なる優先度に対するオフセットの境界、または要求間の最小遅延等）が省略されている。別の実施形態において、図３６に示される要素以外の要素が輻輳制御パラメータを割り当てるために使用され、そして少なくともいくつかの実施形態において、図３６に示される要素全てが考慮される必要があるとは限らないことに留意されたい。例えば、いくつかの実施形態において、輻輳制御技術は、同時順次読み出しにのみ使用され得る。

図３８は、少なくともいくつかの実施形態による、格納サービスにおいてＩ／Ｏ動作をスケジューリングするためにオフセットベース輻輳制御を実施するように実行され得る動作の態様を例示するフロー図である。構成要素３８０１に示されるように、マルチテナントファイルストアサービスにより管理されている格納オブジェクト（ファイルまたはメタデータ構造等）の論理ブロックＬＢ１の少なくとも一部を対象とするＩ／Ｏ要求（読み出しまたは書き込み）を受信し得る。異なる実施形態において、オフセットベースの輻輳制御決定は、前述の様々なサブシステムのうちのいずれかにおいて、またはサブシステムの組み合わせにより、行われ得る。いくつかの実施形態において、ファイル読み出し／書き込みに関する輻輳制御決定はアクセスサブシステムノードにおいて行われ、一方でメタデータに関する当該決定はメタデータサブシステムにおいて行われ得る。別の実施形態において、データとメタデータの両方に関する輻輳制御決定は、格納サブシステムノードにおいて行われ得る。Ｉ／Ｏ要求を遂行するために１つまたは複数の格納動作を実行する対象となる、論理ブロックＬＢ１内のオフセットが特定され得る（構成要素３８０４）。

オフセットの少なくとも一部に基づいて、１つまたは複数の輻輳制御パラメータの値（例えばトークンバケットから消費するトークン数等のＩＯ要求に割り当てられるコスト値、または格納動作の実行前の遅延）が決定され得る（構成要素３８０７）。少なくともいくつかの実施形態において、選択されたパラメータにより、論理ブロックＬＢ１内のより大きいオフセットの要求は、より小さいオフセットの要求よりも奨励され得る、すなわち高い優先度が与えられ得る。そして選択された輻輳制御パラメータに従って、Ｉ／Ｏ要求に対応する格納動作がスケジュールされ得る（構成要素３８１０）。少なくともいくつかの実施形態において、ある種類のＩ／Ｏ要求に関して、応答が要求者に提供され得る（構成要素３８１３）。本明細書において説明されるものと同様のオフセットベースの輻輳制御技術は、異なる実施形態内の様々な格納サービス環境において使用され、これには、ファイルシステムインターフェイス／プロトコルを実施するサービス、格納オブジェクトがユニバーサルレコード識別子（ＵＲＩ）に対応付けられるウェブサービスインターフェイスを実行するサービス、またはブロックレベルデバイスインターフェイスを実行するサービスが含まれることに留意されたい。

オブジェクト名無撞着変更技術
分散ファイル格納サービスにおいて、オブジェクト名変更動作、例えば顧客要求に応じてファイルまたはディレクトリの名前を変更するために実行される動作は、少なくともいくつかの事例において、複数のメタデータノード（または、メタデータサブシステムがメタデータ構造を格納サブシステムに格納する場合は、複数の格納ノード）において格納されるメタデータ要素の更新を伴い得る。このような複数ノード名前変更を実行するために、前述の分散トランザクション技術が使用され得るが、少なくともいくつかの実施形態において、別の名前変更特有機構が後述のように使用され得る。図３９は、少なくともいくつかの実施形態による、名前変更動作を実行するために、ファイル格納サービスの複数のメタデータサブシステムノードにおいて実行される必要があり得るメタデータ変更の例を示す。例としてファイル名「Ａ．ｔｘｔ」を「Ｂ．ｔｘｔ」に変える必要のあるメタデータ変更が示されるが、同様の変更がディレクトリ名変更、リンク名変更等にも行われ得る。描かれた実施形態において、格納サービスの３つのメタデータサブシステムノード３９２２Ａ、３９２２Ｋ、３９２２Ｐが示される。例えば１つまたは複数の格納ノードにおけるオブジェクトに使用されている物理ページの識別、オブジェクトの所有者のユーザ識別子及び／またはグループ識別子、オブジェクトの現行サイズ、最終変更時間、アクセス許可もしくはＡＣＬ（アクセス制御リスト）、オブジェクトを示すハードリンクの数を示すリンク数等を含む、最初に「Ａ．ｔｘｔ」と命名された特定のファイルストアオブジェクトの様々な属性３９１２が、メタデータノード３９２２ＡにおけるＤＦＳ‐Ｉノード３９１０と示されるＤＦＳノードエントリ構造に格納され得る。ＤＦＳ‐Ｉノード構造３９１０は、多数の従来のファイルシステムに実装されるＩノード構造の概念において類似し、そしてファイル格納サービスの分散特性に起因するＤＦＳ‐Ｉノードの追加または変更機能のある集合を有する。

描かれた実施形態において、ファイルストアオブジェクトの名前「Ａ．ｔｘｔ」（名前変更動作のワークフローの実行前）は、別のメタデータノード３９２２ＫにおけるＤＦＳディレクトリエントリ３９３０と呼ばれる別のメタデータ構造に格納され得る。ＤＦＳディレクトリエントリ３９３０は、オブジェクト名のためのフィールド３９３４と、オブジェクトの属性を格納するＤＦＳ‐Ｉノード３９１０を示すポインタとを含み得る。少なくともいくつかの実施形態において、ＤＦＳディレクトリエントリ３９３０は、オブジェクトの親ディレクトリのＤＦＳディレクトリエントリを示すＤＦＳ親ディレクトリポインタ３９５２も含み得る。従って、例えば、「Ａ．ｔｘｔ」がディレクトリ「ｄｉｒ１」内に存在する場合、ＤＦＳ親ディレクトリポインタは、「ｄｉｒ１」のＤＦＳディレクトリエントリを示し得る。ＤＦＳディレクトリエントリのメタデータ構造は、この後の論述において簡潔にディレクトリエントリと称され、同時にＤＦＳ‐Ｉノード構造は、簡潔にノードエントリと称され得る。

所定オブジェクトのディレクトリエントリを管理するために選ばれる特定のメタデータノード３９２２Ａは、異なる実施形態において、例えばオブジェクトが作成された時にオブジェクトの名前をハッシュ化することによる、またはメタデータノードの現在利用可能な作業処理能力もしくは利用可能な格納領域に基づいてメタデータノードを選択することによる等、異なる技術を使用して選択され得る。その結果、少なくともいくつかの事例において、「Ａ．ｔｘｔをＢ．ｔｘｔに名前を変更する」の第２のオペランド（「Ｂ．ｔｘｔ」）のために作成するディレクトリエントリを管理するために、別のメタデータノード３９２２Ｐが選択され得る。

「Ａ．ｔｘｔ」から「Ｂ．ｔｘｔ」への名前変更を実行するために必要な変更が、図３９において「名前変更前ステート３９４５」と「名前変更後ステート３９４７」という表示により示される。名前変更ワークフローを実行するために、「Ｂ．ｔｘｔ」に設定されたオブジェクト名フィールド３９３８と、ＤＦＳ‐Ｉノード３９１０を示すポインタフィールドとを有する新たなディレクトリエントリ３９３１が作成される必要があり、そしてオブジェクト名フィールド「Ａ．ｔｘｔ」を有する元のディレクトリエントリ３９３０は削除される必要がある。少なくともいくつかの実施形態において、ノードエントリ３９１０自体は、名前変更中に変更され得ない。一貫性のために、図３９に示されるメタデータ変更の組み合わせは、全ての変更（関与する両方のメタデータノードにおける）が成功、そうでなければ全て失敗というやり方で実行される必要があり得る。いくつかの実施形態において、前述のように、メタデータ構造は、サービスの格納サブシステムノードの物理格納デバイスにおいて実施されるエクステントを使用して、実際に格納され得る。全て失敗という後半のシナリオにおいて、元のディレクトリエントリ（「Ａ．ｔｘｔ」のディレクトリエントリ）のメタデータノードと格納ノードと、新たなディレクトリエントリ（「Ｂ．ｔｘｔ」のディレクトリエントリ）のメタデータノードと格納ノードという、４つの種類のエンティティが名前変更ワークフローに関与し、そのうちのいずれか１つが他とは関係なく失敗し得る、または受信もしくは発信ネットワークパケットを単独で失い得る。従って、参加ノードのうちのいずれにおいても可能性のある失敗及び／または通信遅延を捕らえるように設計された名前変更ワークフローは、後述のように少なくとも２つの原子動作のシーケンスを使用して実行され得る。シーケンスの各原子動作は、メタデータノードのうちの１つに限定され、そのため、複数ノードの原子動作よりも実行するのが容易であり得る。関与する各メタデータノード（及び／または格納ノード）は、マルチテナント環境における格納サービスの多数のクライアントに属している可能性のある多数のファイルストアオブジェクトのメタデータを管理するように構成され、結果として、各メタデータノードまたは格納ノードは、多数の名前変更要求及び他のファイルストア動作要求を同時に処理する必要があり得ることに留意されたい。

非一貫性及び／またはメタデータ破損を防ぐために、いくつかの実施形態において、ディレクトリエントリ等のメタデータ構造は、名前変更ワークフローの間ロックされ得る（例えば排他ロックを使用して）。デッドロックを防ぐために（例えば２つの名前変更要求「Ａ．ｔｘｔをＢ．ｔｘｔに名前を変更する」と「Ｂ．ｔｘｔをＡ．ｔｘｔに名前を変更する」が時間的に非常に近接して受信された場合に起こる可能性があり得るため）、少なくともいくつかの実施形態において、ロック順序プロトコルが採用され得る。図４０は、少なくともいくつかの実施形態による、同時名前変更動作に対するこのようなデッドロック回避機構の使用を例示する。描かれた実施形態において、デッドロック回避分析モジュール４００４（例えばメタデータサブシステムのサブコンポーネント）は、名前変更要求のオペランド４００１（例えば「ＸをＹに名前を変更する」要求のオペランド「Ｘ」及び「Ｙ」）を入力として受け取り、特定のロック取得命令を生成する。

描かれた実施形態において、二者択一的ロック取得シーケンス４０１０、４０１２が「ＸをＹに名前を変更する」要求に関して示され得る。当該２つのシーケンスのうちの１つのみがデッドロック回避分析モジュール４００４により出力として生成され得る。取得シーケンス４０１０によれば、Ｘのディレクトリエントリに対するロックが、名前変更ワークフローの第１原子動作の一環として確保される。取得シーケンス４０１２によれば、Ｙのディレクトリエントリが、名前変更ワークフローの第１原子動作において取得される（必要であればディレクトリエントリの作成後に）。描かれた実施形態において、ロックシーケンスに到達するために、デッドロック回避モジュールにより名前比較器４００８が使用され得る。２つのオペランドは、例えば辞書順で比較され、そして少なくともいくつかの実施形態において、辞書順が１番目のオペランドが、第１原子動作においてロックされるものとして選択され得る。（別の実施形態において、辞書順が２番目のオペランドが最初にロックされ得る。順序付け論理が異なる名前変更動作にわたって一貫して適用される限り、オペランドのうちどの特定のものが最初にロックされるかは問題になり得ない。）従って、このような実施形態において、変更要求が「ＸをＹに名前を変更する」であるか「ＹをＸに名前を変更する」であるかに関係なく、同じディレクトリエントリが最初にロックされ得る。２つの要求「ＸをＹに名前を変更する」と「ＹをＸに名前を変更する」がほぼ同時に受信されたとしても、このようにして、第１要求のためにＸがロックされ、第２要求のためにＹがロックされることは不可能であることから、デッドロックは回避され得る。いくつかの実施形態において、名前変更オペランド間のロック順序を決定するために、辞書的比較ではない技術が使用され得る。複数のオブジェクト(例えば複数ファイルまたはディレクトリ）は所定のファイルストア内で同一の名前を有し得るが、ＤＦＳ‐Ｉノードに割り当てられた識別子は通常ファイルストア内で一意的であると見込まれ得るため、少なくともいくつかの実施形態において、比較器の入力として使用される「名前」は、オブジェクトに対応付けられた選択ＤＦＳ‐Ｉノード（例えばオブジェクトの親ＤＦＳ‐Ｉノード）の識別子をオブジェクトの名前と連結あるいは結合することにより、取得され得る。ファイル名（またはディレクトリ名）の再利用という潜在的問題を克服するために、別の実施形態において別の一義化技術が使用され得る。例えば、一実施形態において、ロックシーケンスを決定するための「名前」として、ファイルストアのルートからオブジェクトまでのパス全体が使用され得る、あるいはパスのディレクトリのうちのいくつかに対応付けられたＤＦＳ‐Ｉノードの識別子がオブジェクト名と結合され得る。

少なくともいくつかの実施形態において、デッドロック回避分析の出力に基づいて、２つの異なる名前変更ワークフローのうちの１つが、所定の名前変更要求に実施され得る。２つのワークフローは、どのディレクトリエントリが最初にロックされるかという点で異なり得る。それぞれの名前変更ワークフローは、原子的に実行される動作の第１集合（ワークフローの「第１原子動作」と集合的に称され得る）、原子的に実行される動作の第２集合（「第２原子動作」と集合的に称され得る）、そして実施依存であり得る原子性を有する動作の第３集合という、少なくとも３つのフェーズを有すると考えられ得る。追加（一般に非同期的）フェーズも、後述のいくつかの事例において含まれ得る。図４１は、少なくともいくつかの実施形態による、名前変更動作のために格納サービスにおいて特定され得る、２つの可能なロック順序のうちの第１ロック順序に基づいて、第１名前変更ワークフローを実施するために実行され得る動作の態様を例示するフロー図である。構成要素４１０１に示されるように、ファイルまたはディレクトリ等の特定のファイルストアオブジェクトの現行の名前「Ａ」を「Ｂ」に変更する要求が、例えば分散格納サービスのメタデータサブシステムにおいて受信され得る。例えば、アクセスサブシステムノードは、顧客からの名前変更命令を受信し、選択されたメタデータノードへ対応する内部名前変更要求を送信し得る。メタデータとデータの両方にサービスの格納サブシステムが使用される実施形態において、メタデータノードは、例えば格納ノードと同じハードウェアサーバに一緒に配置されるプロセスまたはスレッドを有し得る。「Ａ」のディレクトリエントリは、所有者識別子、読み出し／書き込み許可等のオブジェクトの様々な属性の値を有するノードエントリＤＩ１を、現時点で示し得る。「Ｂ」のディレクトリエントリはまだ存在しないかもしれない。

例えばデッドロック回避分析に基づいて、名前変更ワークフローの一環として「Ａ」のディレクトリエントリに対するロックを最初に確保するか、または「Ｂ」のディレクトリエントリ（まずは作成される必要があり得る）に対するロックを最初に確保するかが決定され得る（構成要素４１０４）。Ｂのディレクトリエントリを最初にロックする場合（構成要素４１０７）、図４１において「４２０１へ進む」という表示で示されるように、図４２において例示されるワークフローステップが使用される。「Ａ」のエントリを最初にロックする場合（同様に構成要素４１０７にて特定）、格納サービスの特定のメタデータノードＭＮ１において、名前変更ワークフローの第１原子動作が試行され得る（構成要素４１１０）。描かれた実施形態において、第１原子動作には、（ａ）「Ａ」のディレクトリエントリに対するロックＬ１を確保することと、（ｂ）試行されているワークフローの名前変更ワークフロー一意的識別子ＷＦＩＤ１を生成することと、（ｃ）オブジェクトの現在の名前ＡをＢに変更することを示すインテントレコードＩＲ１を格納することの以上のステップが含まれ得る。少なくともいくつかの実施態様において、インテントレコードは、ワークフロー識別子ＷＦＩＤ１を含む、または示し得る。一実施態様において、３つのステップを１つの原子動作に合併するのに、格納サービスのステート管理サブコンポーネント（例えば図１２に例示される複製ステートマシンと同様である）が使用され得る。第１原子動作の３つのステップが相対的に実行される順番は、異なる実施態様において異なり得る。いくつかの実施形態において、ロックＬ１、インテントレコードＩＲ１、及び／またはワークフロー識別子ＷＦＩＤ１の表現はそれぞれ、例えば前述の格納サブシステムのエクステントレプリカを使用して、永続性格納デバイス上に複製され得る。少なくとも一実施形態において、ロック、インテントレコード、及び／またはワークフロー識別子を格納するために選択される永続性格納場所は、ＭＮ１に障害が起こった時の代替メタデータノードからアクセス可能であり得る。描かれた実施形態において、ロックＬ１が保持される限り、「Ａ」のディレクトリエントリに対し、他の変更は一切適用され得ない。第１原子動作が試行された時に、例えばある他の同時または略同時変更動作のために、既にロックが保持されている場合、第１原子動作は、ロックが利用可能になるまで延期され得る。

構成要素４１１３において決定されるように、最初の原子動作が成功した場合、名前変更ワークフローの第２原子動作が試行され得る。図４１、４２において例示されるそれぞれのワークフローの原子動作に関して、少なくともいくつかの実施形態において、最初の試行で原子動作を完了できなかった時、原子動作は１回または複数回再試行され得る（例えばある設定可能最大試行数に基づいて）ことに留意されたい。「Ｂ」のディレクトリエントリを管理及び／または格納するように指定されたメタデータノード（ＭＮ２）において、第２原子動作が実行され得る。いくつかの実施形態において、ＭＮ１において第１原子動作が完了した後に、第２原子動作を実行する要求がＭＮ１からＭＮ２へ送信され得る。少なくともいくつかの実施態様において、要求は、ワークフロー識別子ＷＦＩＤ１を含み得る。構成要素４１１６に示されるように、第２原子動作には、（ａ）「Ｂ」のディレクトリエントリが、ある他の変更動作のために現在ロックされていないことを確認することと、（ｂ）名前を変更しているオブジェクトのノードエントリＤＩ１を示すようにＢのディレクトリエントリを設定することと、（ｃ）識別子ＷＦＩＤ１を有するワークフローに関して、「Ｂ」のディレクトエントリのポインタ変更ステップが成功したことを示すレコードを格納することの以上のステップが含まれ得る。少なくともいくつかの事例において、第２原子動作を試行した時に「Ｂ」のディレクトリエントリは存在しないかもしれない。この場合、「Ｂ」のディレクトリがロックされていないかの確認ステップは、非明示的に「Ｂ」の新たなディレクトリエントリを作成することで実行され得る。少なくともいくつかの実施形態において、例えば「Ｂ」ディレクトリエントリの任意の同時変更を防ぐために、Ｂのディレクトリエントリに対するロックは、ポインタが変更される前に確保され得る。いくつかのこのような実施形態において、ＤＩ１を示すポインタが設定された後に、ロックは解除され得る。第１原子動作の一環として実行される書き込みの事例のように、第２原子動作の書き込み（例えばポインタの設定及び成功開示）は、ＭＮ２における障害発生時にそれらを後に読み出すことが可能な複製エクステント等の永続性格納場所において行われ得る。書き込みの組み合わせの原子性を施行するために、格納サービスのステート管理サブコンポーネントが使用され得る。

第２原子動作が成功した場合（構成要素４１１９にて特定）、第３動作集合が試行され得る（構成要素４１２２）。第１原子動作のように、この第３動作集合もＭＮ１において実行され得る。少なくともいくつかの実施形態において、ＭＮ１で受信される第２原子動作が成功したという開示（例えばＭＮ１からＭＮ２へ送信した第２原子動作の要求に対する応答）をきっかけに、第３動作集合が開始され得る。第３動作集合において、「Ａ」のディレクトリエントリに確保されていたロックＬ１は削除され、インテントレコードＩＲ１は削除され、そして「Ａ」のディレクトリエントリ自体も削除され得る。先に述べたように、いくつかの実施態様において、この第３動作集合も原子単位として実行され得る。このような場合、第３動作集合は、ワークフローの「第３原子動作」と称され得る。別の実施態様においては、第３動作集合に原子性は施行され得ない。第１原子動作（例えばインテントレコード、ワークフロー識別子、及びロック開示）中に生成されたメタデータが永続性格納場所に格納される実施形態において、様々な種類の障害により１回または複数回再試行が要求されたとしても、第３集合が原子的に実行されるか否かに関係なく、第３動作は最終的に成功するものと予想され得る。第３動作集合も成功した場合（構成要素４１２５にて検出）、名前変更ワークフローは全体として成功したとみなされ得る（構成要素４１２８）。少なくともいくつかの実施形態において、名前変更が成功したことを示す名前変更要求への応答が送信され得る。いくつかの実施形態において、要求者に対し何も応答は送信され得ない。

描かれた実施形態において、２つの原子動作のうちのいずれかが成功しなかった場合、全体としてのワークフローはアボートされ（構成要素４１３１）、そしてワークフローの前の部分で生成されたレコードのうちのいずれかが削除され得る（インテントレコードＩＲ１、ロックＬ１の確保の表現、及び／またはＭＮ２に格納されている成功レコード等）。第３動作集合のうちいずれかの動作が失敗した場合（構成要素４１２５にて検出）、描かれた実施形態において、構成要素４１２２へ戻る矢印により示されるように、第３動作集合は単純に再試行され得る。先に述べたように、少なくともいくつかの実施形態において、失敗を公表する前に、それぞれの原子動作に対し複数の試行が行われ得る。いくつかの実施形態において、識別子ＷＦＩＤ１を有するワークフローの第３動作集合が完了した後のある時点で、例えば第３動作集合の完了とは非同期的に、ＭＮ２に格納されている成功レコードが削除され得る（構成要素４１３４）。

図４１の構成要素４１０７の否定出力に示されるように、「Ｂ」のディレクトリ変更を最初にロックする場合には、別の名前変更ワークフローが試行され得る。図４２は、少なくともいくつかの実施形態による、名前変更動作のために格納サービスにおいて特定され得る、２つの可能なロック順序のうちのこのような第２ロック順序に基づいて、第２名前変更ワークフローを実施するために実行され得る動作の態様を例示するフロー図である。第２ワークフローも、描かれた実施形態において、「Ａ」から「Ｂ」へ名前を変更するために使用される２つの連続した原子動作を含み、そして実装により、原子的に実行され得る、あるいはされ得ない動作の第３集合がこれらに続く。メタデータノードＭＮ２（オブジェクト名「Ｂ」のディレクトリエントリを格納する責任を担うノード）において実行される第１原子動作（図４２の構成要素４２０１）には、ある他の動作のために「Ｂ」のディレクトリエントリがロックされていないことを確認することと、必要であれば「Ｂ」のディレクトリエントリを作成することと、「Ｂ」のディレクトリエントリをロックすることと、名前変更ワークフローの一意的ワークフロー識別子ＷＦＩＤ２を生成し格納することと、オブジェクトの現在の名前「Ａ」を「Ｂ」に変更することを示すインテントレコードＩＲ２を格納することとが含まれ得る。いくつかの実施態様において、インテントレコードＩＲ２は、ワークフロー識別子ＷＦＩＤ２を含む、または示し得る。

第１原子動作が成功した場合（構成要素４２０４にて検出）、ワークフローＷＦＩＤ２の第２原子動作が試行され得る（構成要素４２０７）。この第２原子動作は、「Ａ」のディレクトリエントリが管理されるメタデータノードＭＮ１において実行され、いくつかの実施形態においては、第１原子動作が成功したことを示すＭＮ２からの要求をきっかけに開始され得る。第２原子動作には、Ａのディレクトリエントリがロックされていないことを確認することと、「Ａ」のディレクトリエントリを削除することと、ワークフロー「ＷＦＩＤ２」の一環として「Ａ」のディレクトリエントリがうまく削除されたことを示す永続性レコードを格納することとが含まれ得る。第２原子動作が成功した場合（構成要素４２１０にて特定）、第３動作集合がＭＮ２において試行され得る（構成要素４２１３）。いくつかの実施形態において、例えば前にＭＮ２からＭＮ１へ送信した第２原子動作の要求に対しＭＮ２で受信する応答等、第２原子動作が成功したという開示をきっかけに、第３動作集合を実行する試行が開始され得る。第３動作集合には、「Ｂ」のディレクトリエントリがＤＩ１（名前を変更しているオブジェクトのノードエントリ）を示すように設定することと、ロックＬ２を解除／削除することと、インテントレコードＩＲ２を削除することとが含まれ得る。

第３動作集合が成功した場合（構成要素４２１６にて検出）、ワークフローは全体として成功したとみなされ（構成要素４２１９）、いくつかの実施形態においては、名前変更動作の要求者に対し成功インジケータが返され得る。図４１に例示されるワークフローのように、図４２の第３動作集合は、失敗のシナリオにおいては構成要素４２１６から構成要素４２１３へ戻る矢印により示されるように１回または複数回再試行が要求され得るが、最終的には成功するものと予想され得る。少なくともいくつかの実施形態において、第３動作集合の完了とは非同期的に、ＭＮ１に格納されている成功レコード（「Ａ」のディレクトリエントリは削除されたことを示す）自体が削除され得る（構成要素４２２５）。２つの原子動作のうちのいずれかが成功しなかった場合、全体としての名前変更ワークフローはアボートされ（構成要素４２２２）、そしてアボートされたワークフローの前の動作中に格納されたレコードは一掃され得る。図４１において例示される動作のように、第２ワークフローの原子動作に、格納サービスのステート管理機構及び／または複製エクステントが使用され得る。

使用されているファイルシステムプロトコルにより見込まれる所望レベルの一貫性を達成するために、デッドロック回避ロック順序シーケンスと、図４１及び図４２に例示される動作とを使用して、ファイルストアオブジェクトの名前変更動作は実行され得る。一意的ワークフロー識別子に対応付けられたインテントレコードを永続性格納場所に格納する技術は、異なる実施形態において、様々な種類の障害からの復旧に役立ち得る。図４３は、少なくともいくつかの実施形態による、名前変更ワークフローに参加する１対のメタデータサブシステムノードのうちの１つのメタデータサブシステムノードにおける障害に応じて実行され得る復旧動作の態様を例示するフロー図であり、一方図４４は、少なくともいくつかの実施形態による、名前変更ワークフローに参加する１対のメタデータサブシステムノードのうちのもう１つのメタデータサブシステムノードにおける障害に応じて実行され得る復旧動作の態様を例示するフロー図である。説明を簡潔にするために、図４１において例示されるワークフローシーケンス中に単一のメタデータノードに障害が起こった場合に実行され得る動作を、図４３と図４４のそれぞれが例示するが、少なくともいくつかの実施形態において、ワークフローに関与する両方のメタデータノードに障害が起こった場合でも、同様の復旧方策が採用され得る。

図４３の構成要素４３０１において示されるように、図４１のワークフローシーケンスの第１原子動作（構成要素４１１０に例示されるステップを有する）が完了した後、かつ図４１のワークフローシーケンスの第３動作集合（構成要素４１２２）が始まる前のある時点で、ノードＭＮ１の障害が検出され得る。例えば、「Ａ」のディレクトリエントリが管理されるメタデータノードＭＮ１を実行するプロセスまたはスレッドが早く終了してしまう、あるいはネットワーク関連障害のせいで、またはハングアップに至るソフトウェアバグのせいで、ＭＮ１がヘルスチェックに無反応になってしまう、ということがあり得る。このような状況の下、描かれた実施形態において、代替メタデータノードＭＮ‐Ｒが、ＭＮ１の責務を引き継ぐように設定または指定され得る（構成要素４３０４）。いくつかの実施形態において、先に述べたように、ＭＮ１は、複数のメタデータノードを含む冗長グループのメンバーとして設定されており、そしてフェイルオーバー用に事前設定された冗長グループの別のメンバーが代替として素早く指定され得る。別の実施形態において、代替メタデータノードＭＮ‐Ｒは、事前設定された冗長グループに属し得ない。

図４１のワークフローの第１原子動作において、ＭＮ‐１は永続性格納場所に、インテントレコードＩＲ１とワークフロー識別子ＷＦＩＤ１を、ロックＬ１の表現と共に格納した。代替メタデータノードＭＮ‐Ｒは、ＭＮ‐１の障害の前に書き込まれたインテントレコードＩＲ１とワークフロー識別子ＷＦＩＤ１を読み出し得る（構成要素４３０７）。描かれた実施形態において、ＭＮ‐Ｒはそれから、ワークフローＷＦＩＤ１のステータスを特定するために、「Ｂ」のディレクトリエントリを担当するメタデータノードＭＮ２に対しクエリを送信し得る（構成要素４３１０）。例えばワークフローの第２原子動作の一環として、Ｂのディレクトリエントリポインタは既にＤＩ１（名前を変更しているオブジェクトのノードエントリ）を示すように設定されているか否かを調べるために、ＭＮ‐ＲはＭＮ２にクエリを送信し得る。

先に述べたように、分散格納サービスがマルチテナントである実施形態において、各メタデータノードは、いくつかの異なるファイルのメタデータ、及び／またはいくつかの異なるクライアントのメタデータを管理する責任を担い得る。その結果、ＭＮ２は、多数の名前変更ワークフローの第２原子動作に対応するそれぞれの成功レコードを格納済みであり得る。識別子ＷＦＩＤ１を有するワークフローのステータスに関するクエリを受信すると、ＭＮ２は、ＷＦＩＤ１の成功原子動作のレコードを検索し得る。ＭＮ２がＷＦＩＤ１の第２原子動作の成功レコード見つけた場合（構成要素４３１３にて特定）、ＭＮ２はＭＮ‐Ｒに、第２原子動作は完了していたこと（すなわち「Ｂ」のディレクトリエントリはノードエントリＤＩ１を示すように設定されていたこと）を知らせ得る。従って、描かれた実施形態において、ＭＮ‐Ｒはそれから、ＷＦＩＤ１により識別される名前変更ワークフローを完了するために、第３動作集合を試行し得る（構成要素４３１６）。

少なくともいくつかのシナリオにおいては、ワークフローＷＦＩＤ１の第２原子動作が成功しない場合もあり得る。例えば、第２原子動作を開始するためのＭＮ２に対するＭＮ１の要求がうまく送信される前に、ＭＮ１に障害が起こった、あるいは当該要求が失われた、あるいはＭＮ２は要求された第２原子動作をうまく実行できなかった、ということがあり得る。いくつかの実施形態において、第２原子動作は成功しなかったことがＭＮ‐Ｒに知らされた場合（同様に構成要素４３１３にて特定）、ＭＮ‐Ｒは、ワークフローを中止するか再開するか、いずれかの選択肢を有し得る。描かれた実施形態において、キャンセル基準を満たす場合（構成要素４３１９にて検出）、名前変更ワークフローはアボートされ、そしてＭＮ１に格納されている、ＷＦＩＤ１に対応付けられたメタデータレコードは削除され得る（例えばインテントレコードＩＲ１とロックＬ１の表現は、永続性格納場所から削除され得る）（構成要素４３２２）。一実施形態においては、元の名前変更要求をクライアントから受信してから経過した時間が、ある設定閾値を超える場合に、キャンセル基準は満たされ得る。名前変更ワークフローの経過時間依存終了は、例えば名前変更を要求したクライアントは、長い経過時間を考慮すると、元の要求は成功しなかったことを理解し、そのためこの時点で名前変更が成功することを期待していないであろうという仮定の下で実行され得る。いくつかの実施形態において、識別子ＷＦＩＤ１を有するワークフローがアボート／キャンセルされたことを示すキャンセルレコードがある設定可能な時間、例えばＭＮ‐Ｒ、ＭＮ２、ＭＮ‐ＲとＭＮ２の両方のいずれかにおいて、格納され得る。このような一実施形態において、ワークフローを中止することを決定した後、ＭＮ‐Ｒはまず、キャンセルレコードを格納するようにＭＮ２に要求を送信し、そしてＭＮ‐Ｒは、ＭＮ２がキャンセルレコードを永続性格納場所にうまく格納したことを知らされた後に、インテントレコードとロックの両方を削除し得る。

しかしながら、キャンセル基準が満たされない場合（同様に構成要素４３１９にて検出）、描かれた実施形態において、ＭＮ‐Ｒは、第２原子動作を実行するようにＭＮ２に要求を送信することでワークフローを再開し得る（構成要素４３２５）。様々な実施形態において、ＭＮ１の障害に応じるための他の方策が実行され得る。例えば、いくつかの実施形態において名前変更ワークフローは、最初に名前変更要求を受信してから経過した時間に関係なく常に再開され、そして少なくとも一実施形態において名前変更ワークフローは、第１原子動作の完了後にＭＮ１に障害が発生すると常に中止され得る。

図４４は、少なくともいくつかの実施形態による、図４１に例示されるワークフローシーケンス中にメタデータノードＭＮ２に障害が起こった場合に実行され得る動作を例示する。構成要素４４０１において示されるように、例えばワークフローの第２原子動作（構成要素４１１６）を実施するように要求をＭＮ２へ送信した後に、ＭＮ２の障害が検出され得る。ＭＮ１をＭＮ‐Ｒで置き換えることに関して前述された方法と同様の方法で、描かれた実施形態においてＭＮ‐Ｒに対し代替メタデータノードＭＮ‐Ｒ２が指定または設定され得る（構成要素４４０４）。ＭＮ‐Ｒ２は、ＭＮ２が障害の前に永続性格納場所に書き込んだ成功レコードを読み出すことが可能であり得る。

識別子ＷＦＩＤ１を有するワークフローの第２原子動作がうまく完了したか否かに関してＭＮ１が特定できるように、ＭＮ１からのクエリをＭＮ‐Ｒ２において受信し得る（構成要素４４０７）。第２原子動作がＭＮ２の障害の前に完了していた場合（構成要素４４１０にて検出）、ＭＮ‐Ｒ２はＷＦＩＤ１の成功レコードを見つけることが可能であり、ＭＮ１に適宜応答し得る。ＭＮ１はそれから、第３動作集合を試行することで、ワークフローを再開し得る（構成要素４４１３）。

ＷＦＩＤ１の第２原子動作が完了していない場合、図４３において実施されたものと同様の手続きが、図４４において描かれる実施形態において実行され得る。名前変更動作のキャンセル基準が満たされる場合（構成要素４４１６にて検出）、例えば名前変更が要求されてから経過した時間がある閾値時間Ｔを超える場合、名前変更動作はアボートされ、そしてＷＦＩＤ１に関連するデータ構造が一掃され得る（構成要素４４１９）。そうではなくキャンセル基準が満たされない場合、第２原子動作を実行するように要求をＭＮ１がＭＮ‐Ｒ２へ送信することにより、ワークフローは再開され得る（構成要素４４２２）。

図４３と図４４は、図４１のワークフロー中にいずれかのメタデータノードに起きた障害に応じる復旧技術を例示したが、少なくともいくつかの実施形態において、図４２に例示されるワークフロー中にいずれかのメタデータノードに障害が起きた場合にも、類似技術が実行され得る。障害の起きたメタデータノード用に設定された代替ノードが、永続性格納場所からワークフローレコード（例えばインテントレコード、ロック、及び／または成功レコード）を読み出し可能である限り、障害の後にワークフローを再開することは可能であり得る。例えば、図４２のワークフローにおいて、第１原子動作の後にＭＮ２に障害が起こり、代替ＭＮＲ‐２が指定された場合、ＭＮＲ２は、インテントレコードＩＲ２とワークフロー識別子ＷＦＩＤ２とを読み出し、ＭＮ１に関するステータスクエリを送信する等を行い得る。図４３、４４において示されるものと同様の方法で、障害を検出して代替ノードを設定するのにかかる時間と、障害の前の名前変更ワークフローの進捗程度とによって、いくつかの事例において図４２の名前変更ワークフローは、メタデータノードの障害の後に中止され得る。データに使用されているものと同じ基礎格納サブシステムを使用してメタデータが格納される実施形態において、図４３と図４４において例示されるものと同様の復旧技術が、格納ノードの障害に応じるためにも使用され得る。いくつかの実施形態において、メタデータノードと格納ノードの機能は、同じホストまたはハードウェアサーバにおいて実行され、その結果、そのホストまたはサーバの障害は、両種のノードに影響を及ぼし得る。

拡張縮小可能な名前空間管理
分散格納サービスの目的には、非常に多くの数のファイル、ディレクトリ、リンク、及び／または他のオブジェクトを、様々な実施形態において拡張縮小可能なやり方で処理することが含まれ得る。例えば、一部の大きな顧客に対して、所定のファイルシステムは百万以上のディレクトリを有し、そして所定のディレクトリは百万以上のファイルを有し得る。いくつかの実施形態において、そのようなレベルまで名前空間内のオブジェクトの数が増加しても、ディレクトリのリスト作成、検索、挿入、削除等の様々な名前空間動作に関して、大量処理に対応するために、及び／または同時処理度が高い時に確実に応答時間が比較的に一律であり続けるようにするために、ハッシュ有向非巡回グラフ（ＨＤＡＧ）と呼ばれるデータ構造が、名前空間のエントリを管理するのに使用され得る。本明細書において使用される用語の名前空間は、所定ファイルシステムまたは他のデータストア論理コンテナ内に作成されるオブジェクト（ファイル、ディレクトリ、ハード及びソフトリンク等）の名前の集合と、オブジェクト間の関係（例えば親子関係）とを指すのに使用される。いくつかの実施形態において、例えばサービスのメタデータサブシステムにより、ファイルシステムのディレクトリごとにそれぞれのＨＤＡＧが生成され得る。後述されるＨＤＡＧベースの名前空間管理技術は、複数の格納エクステントにわたる設定可能な粒度でのメタデータ構造のストライピング、及び単一原子動作において複数の格納デバイスにて変更を実行する能力等、前述された分散格納サービスの機能のうちのいくつかを使用し得る。例えば、一実施態様において、特定のＨＤＡＧの各ノードに、それぞれの論理ブロック（それぞれのエクステントの１つまたは複数のページにマッピングされ得る）が使用され得るため、複数の格納サーバ間で、名前空間エントリが分割される可能性がある。

図４５は、少なくともいくつかの実施形態による、ファイルストア名前空間管理に使用され得るハッシュ有向非巡回グラフ（ＨＤＡＧ）の例を示す。ディレクトリのＨＤＡＧは、描かれた実施形態において、少なくとも２種類のノード、エントリリスト（ＥＬ）ノード（図３９に示されるＤＦＳディレクトリエントリ構造と同様のディレクトリエントリと、対応するオブジェクトの他の属性値を含むそれぞれのＤＦＳ‐Ｉノードを示すポインタとのリストを、それぞれが有する）と、ノード識別子アレイ（ＮＩアレイ）ノード（子ノードの集合を示すポインタのアレイをそれぞれが有する）とを含み得る。ノードの種類は、ヘッダーフィールド４５０４Ａまたは４５２０Ａ等のヘッダーフィールドに示され得る。ディレクトリＤ１が作成されると、単一ＥＬノード（ＨＤＡＧのルートノードと称されるノード４５００Ａ等）を含む初期ステート４５９０ＡのＨＤＡＧが、ディレクトリのために作成され得る。いくつかの実施態様において、ディレクトリのＤＦＳ‐Ｉノード自体が、ＨＤＡＧのルートノードとして使用され得る。ルートノード４５００Ａは、ディレクトリ属性４５０２Ａのある集合と、ルートノードの種類（最初はＥＬ）を示すヘッダーフィールド４５２０Ｒと、Ｄ１内に作成された最初のいくつかのファイルまたはサブディレクトリのルートエントリリスト４５０６とを保持するのに十分な領域を有し得る。所定のＥＬノードは、ある設定可能な数（例えば所定のファイルストアの全てのＥＬエントリに選択され得る値）までの名前空間エントリを格納可能であり、そして所定のＮＩアレイノードは、ある設定可能な数（例えば所定のファイルストアの全てのＮＩアレイエントリに選択される別の値）までのノード識別子を格納可能である。少なくともいくつかの実施形態において、ＨＤＡＧノードの最大許容サイズは、１つのＨＤＡＧノードのコンテンツが単一原子動作において格納領域に書き込み可能なサイズに決定され得る。例えば一実施態様において、ＨＤＡＧノードの占有領域が決して４キロバイトを超えないようにＨＤＡＧパラメータが選択される場合、４キロバイトのページに対応するエクステントがＨＤＡＧに使用され、及び／または４キロバイトの論理ブロックサイズが使用され得る。他のＨＤＡＧ間マッピング、論理ブロックサイズ、及びページサイズが、別の実施態様において使用され得る。

Ｄ１内にさらにファイルまたはサブディレクトリが追加されると（矢印４５２５により示されるように）、ルートエントリリスト４５０６は最後には一杯となり、ルートノード４５００Ａは、そのエントリリストのメンバーを子ノードに分散するために、ハッシュ関数を使用して、ある数の子ノードに分割され得る。ルートノードの種類はＥＬからＮＩアレイに変更され、そして子ノードを示すポインタ（例えば子ノードが格納される論理または物理格納アドレス）が、ルートノードのＮＩアレイ内のそれぞれの要素に書き込まれ得る。所望するサイズのハッシュ値を生成するために、それぞれのエントリ名（例えばファイル名、サブディレクトリ名）に選択された強力なハッシュ関数が適用され、そして所定のエントリを新たな子ノードにマッピングするのに、所定のエントリのハッシュ値のビットシーケンス表現の一部が使用され得る。様々な実施形態において、一杯になった非ルートノードに対し、新規に作成された子ノード間における同様のハッシュベースのエントリ分散を使用して、いくつかの種類の分割動作（詳しくは後述）が実行され得る。検索要求に応じて、例えば対象エントリを有するノードが見つかるまで、ハッシュ値のビットシーケンス表現の連続するサブシーケンスを、ＨＤＡＧのそれぞれのレベルをナビゲートするためのインデックスとして使用する等、同じハッシュ関数が特定のオブジェクト名のエントリを検索するのにも使用され得る。ディレクトリリストを取得するために、ルートノードのＮＩアレイ（ルートノードは分割したと仮定する）から始まる全てのポインタは、ＨＤＡＧ全体がトラバースされ、かつ全てのそのエントリが取得されるまで、再帰的に追跡され得る。様々な種類のＨＤＡＧ動作に関するさらなる詳細は、後に提供される。

エントリリストノードの種類は、ある条件の下、１つまたは複数の種類のＨＤＡＧの動作の結果で変わり得る。例えば、ルートノード４５００Ａは、そのエントリが子ノード間に分散された後にＮＩアレイとなった（さらに詳しく後述されるように、いくつかの事例において、ＮＩアレイノードは削除後、エントリリストノードに変わり得る）。ＮＩアレイ４５１０Ａは、ステート４５９０ＢのＨＤＡＧ内の子ノード４５５０Ａ、４５５０Ｂ、４５５０Ｃのポインタ（例えば格納アドレス）を含む。ルートエントリリスト４５０６に元から存在したエントリは、子ノードのそれぞれのエントリリスト（例えばノード４５５０Ａのエントリリスト４５２２Ａ、ノード４５５０Ｃのエントリリスト４５２２Ｂ、そしてノード４５５０Ｂに最初に作成された別のエントリリスト）に最初に分散され得る。従って、それぞれの子ノード４５５０Ａ、４５５０Ｂ、４５５０ＣはＥＬノードとして開始し得た。しかしながら、ステート４５９０Ｂに達する時までには、ノード４５５０Ｂ自体が分割し、ＮＩアレイ４５１０Ｂに格納されている自身の子ノード４５５０Ｋ、４５５０Ｌを示すポインタを有するＮＩアレイノードになっている。ステート４５９０Ｂにおいて、ノード４５５０ＬもステートをＥＬからＮＩアレイへ変更し、ノード４５５０ＬのＮＩアレイ４５１０Ｃは、ノード４５５０Ｌの子ノードを示すポインタを含む。ノード４５５０Ｋは、Ｄ１内に作成されたファイル／ディレクトリのうちのいくつかを表すエントリリスト４５２２Ｋを有するＥＬノードのままである。描かれた実施形態において、それぞれのノードのヘッダー（例えばヘッダー４５２０Ｒ、４５２０Ａ、４５２０Ｂ等）は、ノード分割（またはある種類のエントリ削除の後のノード結合）の結果、ノードの種類が変わった時と場合に、変更され得る。いくつかの実施態様において、少なくともいくつかの時点において、ルートノード４５００Ａ及び／または他のＨＤＡＧノードは、使用されていないあるバイト数を有し得る。ステート４５９０Ｂにおいて、ＨＤＡＧは、少なくとも３つの「レベル」、ルートレベルと、ＨＤＡＧレベル１（ルートノードのＮＩアレイポインタを使用して単一検索でアクセス可能なノード４５５０Ａ、４５５０Ｂ、４５５０Ｃを含む）と、ＨＤＡＧレベル２（レベル１のノードのＮＩアレイポインタを使用して単一検索でアクセス可能なノード４５５０Ｋ、４５５０Ｌを含む）とを含むとみなされ得る。用語「ＨＤＡＧレベル」は、ＨＤＡＧのルートノードから開始してある特定のノードにたどり着くまでに遭遇するノードの数を示すものとして、本明細書において使用され得る。子ノードを有さないＨＤＡＧノードは、リーフノードと称され得る。少なくともいくつかの実施形態において、ＨＤＡＧの２つのリーフノードＬ１、Ｌ２に関して、ＨＤＡＧルートからリーフノードに向かうそれぞれのトラバーサル中に、Ｌ２に達するまでに遭遇するノードの数とは異なる数のノードに、Ｌ１に達するまでに遭遇し得る場合もあり得る。図４５に例示される実施形態において、ノード間のエントリの分散、及びその後のエントリの検索に使用するハッシュ値は、ＨＤＡＧ自体に格納する必要はあり得ないことに留意されたい。

前述のように、名前空間管理技術の目的のうちの１つは、名前による高速検索を可能にすることであり得る。図４６は、少なくともいくつかの実施形態による、ファイル名に取得されたハッシュ値の連続サブシーケンスを使用して、ＨＤＡＧをナビゲートする技術を例示する。（同様の技術が、ディレクトリ、リンク、または他のファイルストアオブジェクトに使用され得る。）例えばパラメータとして名前を有する検索要求に応じて、ファイルの名前４６０２は、選択されたハッシュ関数４６０４に対する入力として使用される。いくつかの実施形態において、Ｋ（例えば２５５）ＵＴＦ‐８文字までのストリングが、ファイル名またはディレクトリ名として使用され得る。ファイルストアオブジェクト名の他の長さの制約またはエンコーディングが、他の実施形態において使用され得る。一実施形態において、それぞれのファイルストアに異なるハッシュ関数が使用され得る。例えば、ハッシュ関数は構成パラメータとして特定され得る、あるいはファイルストアの名前空間のサイズの予測、ファイルストアが作成されているクライアントにより提供されるヒント等に基づいて、ハッシュ関数は格納サービスにより選択され得る。少なくとも一実施形態において、所定の数の名前空間エントリのＨＤＡＧの平均レベル数、またはＨＤＡＧの分散度合い（例えば一部のエントリには、他よりもはるかに少ないレベルを通過して到達するか否か）等、使用されているハッシュ関数の有効性に関する様々なメトリクスは経時的に記録され、そして測定された有効性が十分でない場合には、別のハッシュ関数が選択され得る（少なくとも先々の使用のため）。

描かれた実施形態において、（少なくとも）Ｎ^*Ｍビットのシーケンスとして表現可能なハッシュ値４６１０が生成され得る。ＮとＭは設定可能なパラメータである。それぞれＭビットの、ハッシュ値４６１０のＮ個のサブシーケンス（例えばＳ１、Ｓ２、・・・ＳＮ）が、ＨＤＡＧの対応レベルへのインデックスとして使用され得る。例えば、サブシーケンスＳ１は、レベル１をナビゲートするのに使用するＮＩアレイポインタ（ルートノードの）を選択するために使用され得る、サブシーケンスＳ２は、レベル１のノードから開始してレベル２をナビゲートするのに使用するＮＩアレイポインタを選択するために使用され得る、等が挙げられる。所定のサブシーケンスにおける全てのビットが、所定のレベル検索またはレベルナビゲーションに使用される必要があるわけではない。例えばいくつかの事例においては、ｑ個の高位ビット（ｑ＜Ｍ）のみが使用され得る。いくつかの実施形態において、ハッシュ値の一部伸びと４６６６は、どのレベルにも未使用であり得る。

例えばファイルオープン命令またはディレクトリ作成命令に応じて、新たなエントリがファイルストアに追加される時、新たなエントリの名前のハッシュ値が取得され、そして名前がマッピングされたＥＬノード候補が見つかるまで、前述のサブシーケンスベースのナビゲーション技術を使用して、ＨＤＡＧはトラバースされ得る。（いくつかのシナリオにおいて、名前空間にエントリのための領域がなくなる場合もあり得る。このような特別な事例は後述される）。候補ノードのエントリリストに空き領域がもうない場合、または新たなエントリが追加されるとその空き領域が閾値レベルを下回ってしまう場合、候補ノードは分割され得る。分割されたノードのエントリのうち少なくともいくつかは、例えば後述されるエントリのハッシュ値の選択されたサブシーケンスを使用して、ＨＤＡＧに追加される１つまたは複数の新たなノードに分散され得る。いくつかの実施形態において、少なくとも２つの異なる種類のＨＤＡＧノード分割動作が実行され得る。

図４７は、少なくともいくつかの実施形態による、名前空間にエントリを挿入する試みから生じ得る２種類のＨＤＡＧノード分割のうちの第１種のＨＤＡＧノード分割の例を示す。この第１種の分割において、詳しく後述されるように、ＨＤＡＧノードの種類は、エントリリスト（ＥＬ）からＮＩアレイに変更され得る。いくつかの実施形態において、名前空間エントリ挿入は、ファイル等の名前空間オブジェクトを作成するよう求めるクライアント要求に応じて取られるいくつかのステップのうちの１つであり得る。例えば他のステップには、ファイルに対応付けられたＤＦＳ‐Ｉノードオブジェクトに領域を割り当てること、ファイルの初期属性を設定すること、及び／または名前空間エントリからＤＦＳ‐Ｉノードまで、かつ当該Ｉノードからファイルコンテンツを格納するために使用される１つまたは複数の物理ページまでのポインタを設定することが含まれ得る。これらのステップの順序は、異なる実施形態において異なり得る。

「Ｌｉｍａ」という名前（例えばファイル名）のエントリ４７０１を名前空間に挿入する要求が、図４７に示される実施形態において受信され、「Ｌｉｍａ」という名前のオブジェクトの挿入を試みているディレクトリ用に作成されたＨＤＡＧ内をナビゲートした結果、ＥＬノード候補４７５０Ａが検出される。ＨＤＡＧノードの識別子（ＨＤＡＧノードの格納アドレスにも該当し、そのため格納サブシステムに対する読み出しまたは書き込み動作のパラメータとして使用され得る）の最初の一部が、図４７において１６進数文字列として示される。例えば、ノード４７５０はＩＤ「０ｘ４３２ｄ１２．．．」を有する。図４７に例示される第１種のノード分割は、描かれた実施形態において、（ａ）候補ノード４７５０Ａはルートノードである、または（ｂ）ノード４７５０Ａの親ノード（図４７に図示せず）内の１つのＮＩアレイポインタエントリのみがノード４７５０Ａを示す、といういずれかの条件下で試行され得る。描かれた実施形態において、これらの条件のいずれかが満たされる場合、２つの新規のＨＤＡＧノード４７５０Ｂ、４７５０Ｃに領域が割り当てられ得る（例えばそれぞれのメタデータエクステントにおいて）。（説明を簡潔にするために２つの子ノードが図４７において例示されるが、他の実施形態においては、３つ以上の子ノードが分割中に作成され得ることに留意されたい。）ノード４７５０Ａに前から存在したそれぞれのエントリ（例えば「Ａｌｐｈａ」、「Ｂｒａｖｏ」、「Ｃｈａｒｌｉｅ」等）、及び新規エントリ「Ｌｉｍａ」は、「１」と表示された矢印により示されるように、それぞれのハッシュ値に基づいて、新規ノード４８５０Ｂまたは４７５０Ｃのうちの１つにマッピングされ得る。一実施態様において、例えば、候補ノードがＨＤＡＧのＫ番目のレベルに存在する場合、エントリのハッシュ値の（Ｋ＋１）番目のサブシーケンスがハッシュ値の最上位ビットに基づいて並び替えられ、そして最上位ビットが「１」のハッシュ値を有するエントリはノード４７５０Ｂにマッピングされ、最上位ビットが「０」のハッシュ値を有するエントリはノード４７５０Ｃにマッピングされ得る。分割中に３つ以上の子ノードが作成される実施形態においては、エントリをマッピングするのにさらに多くのビットが使用され得る。例えば４つの子ノードが作成される場合、ハッシュサブシーケンス値の２上位ビットが使用され得る等する。描かれた実施形態において、例えばオブジェクト名及びハッシュ関数によっては、必ずしも分割されるノード（描かれた実施例における４７５０Ａ）のエントリが子ノード間に均等に分散されるとは限らず、そして少なくともいくつかの実施形態においては、そのような均等性を達成しようとすることでＨＤＡＧを「均衡化」する試行は全く行われ得ない。その代わりに、このような実施形態において、ノード間で適度に均衡の取れたエントリの分散を達成することは、ハッシュ関数の強度と質に依存し得る。描かれた実施例において、子ノード間でのエントリの分散後、子ノード４７５０Ｂは後続の挿入に使用可能な空き領域４７１０Ａを有し、同時に子ノード４７５０Ｃは後続の挿入に使用可能な空き領域４７１０Ｂを有する。

分割前はＥＬノードだったノード４７５０Ａは、図４７において「２」と表示された矢印により示されるように、ＮＩアレイノードに変換され得る。そのＮＩアレイエントリの半分は、ノード４７５０Ｂを示すように設定され（例えば４７５０ＢのＩＤである０ｘ７８６ａａ２．．．を格納することにより）、そしてもう半分は、ノード４７５０Ｃを示すように設定され得る（例えば４７５０ＣのＩＤである０ｘｃ３２１７６．．．を格納することにより）。エントリを分割するのに最上位ビットが使用された実施態様において、下半分のＮＩアレイエントリ（例えば０から（ＮＩアレイサイズ／２）−１までのインデックスを有するエントリ）はノード４７５０Ｃを指すように設定され（ハッシュ値が「０」で始まるエントリ）、そして上半分のＮＩアレイエントリ（例えば（ＮＩアレイサイズ／２）から（ＮＩアレイサイズ−１）までのインデックスを有するエントリ）は別の子ノード４７５０Ｃを示すように設定され得る。分割の結果、ｎ個の子ノードが作成される実施形態において、１／ｎのＮＩアレイエントリは、それぞれの子ノードを示すように設定され得る。３つのノード４７５０Ａ、４７５０Ｂ、４７５０Ｃに対する変更は、格納サブシステムにおける永続性格納場所に保存され得る。いくつかの実施形態において、例えば前述の分散トランザクション技術を使用して、３つの全てのノードに対する変更が１つの原子動作において実行され得る。別の実施形態において、３つの永続的なノードのうちの少なくとも１つに対する変更を、他のノードから切り離して行うために、前述の条件付き書き込みが使用され得る。

第１種の分割動作を実行するための前に略述された条件が満たされない場合（例えば候補ノードの親ノードが、候補ノードを示す複数のＮＩアレイポインタを有する場合）、第２種の分割動作が実行され得る。図４８は、少なくともいくつかの実施形態による、名前空間にエントリを挿入する試みから生じ得る２種類のＨＤＡＧノード分割のうちの第２種のＨＤＡＧノード分割の例を示す。描かれた実施例において、新規エントリ「Ｑｕｅｅｎ」４８０１の候補ノードとして、ノード４７５０Ｃが特定されるが、ノード４７５０Ｃのエントリリストには空き領域が残っていない。「Ｑｕｅｅｎ」の挿入が試行される時点で、親ノード４７５０Ａは、ノード４７５０Ｃを示す多数のポインタ（例えばＩＤ値０ｘｃ３２１７６．．．を有するＮＩアレイエントリ）を含む。同じ値「０ｘ７８６ａａ２．．．」を有する複数の要素、及び値「０ｘ３２１７６．．．」を有する複数の要素により示されるように、描かれた実施形態において、ＮＩアレイ要素はそれぞれ、ノードのコンテンツが格納されているブロックを示し、ノード内の個別のＥＬエントリは示さない。別の実施形態においては、ブロックレベルポインタの代わりに、またはブロックレベルポインタに加えて、エントリレベルポインタが使用され得る。図４８に描かれたシナリオにおいては、図４７に例示されるような２つのノードの代わりに、１つの新規ノードのみ（ＩＤ０ｘ２２３１２３を有するノード４８５０Ａ）が作成される。図４７において４７５０Ａのエントリに使用したものと同様の方法で、ノード４７５０Ｃのエントリのハッシュ値が計算され得る。ハッシュ値は、最上位ビットに基づいて並び替えられ得る。１と表示された矢印により示されるように、分割時に４７５０Ｃに存在するエントリのうち、最上位ビットに「１」を有するエントリは新規ノード４８５０Ａにマッピングされ、一方残りのエントリ（最上位ビットに「０」を有するもの）はノード４７５０Ｃ内に保持され得る。

描かれた実施形態において、矢印２により示されるように、新規に追加されたノード４８５０Ａにポインタを追加するように親ノードのＮＩアレイエントリが変更され得る。４７５０Ｃを前に示していた４７５０ＡのＮＩアレイエントリのうち、半分（例えばアレイインデックス範囲の上半分）は、新規ノード４８５０Ａを示すように設定され、一方でもう半分は４７５０Ｃを引き続き示し得る。従って、分割後、ノード４７５０ＡのＮＩアレイエントリのうち、半分は４７５０ＢのＩＤ（分割の影響を受けなかった）を含み、４分の１は４７５０Ｃを示し、そして４分の１は４８５０Ａを示し得る。前述の第１種のノード分割の事例のように、いくつかの実施形態において、ＥＬが一杯である候補ノード４７５０Ｃのエントリは、３つ以上のノード（候補ノード自体を含む）に再分散され得る。例えばエントリハッシュ値の２ビットを使用して、全部で４ノードが分散に使用され得る。ある状況の下では、所定ノードの分割は、ＨＤＡＧのルートに向かって上向きに伝播される必要があり得る。例えば、ノードＮ１は挿入のために分割される必要があり、その結果、Ｎ１の親も分割される必要があり得る等する。このような場合、候補者ノードに到達するためにＨＤＡＧをトラバースする手順は、ＨＤＡＧのルートから開始して繰り返される必要があり得る。

図４７、４８に例示される分割動作では、分割が試行される時に、ＨＤＡＧに新しいレベル（例えば新規子ポインタ）が追加され得ると想定する。しかしながら、少なくともいくつかの実施形態において、例えばハッシュ値サイズ、及びＨＤＡＧの各レベルをナビゲートするのに使用されるビット数に基づいて、ハッシュ関数により許容される最大レベル数にある時点で達し、そしてそれ以上のレベルは追加され得ない。このようなシナリオにおいて、図４７と４８に例示されるハッシュベース分割を実行する代わりに、ハッシュベース分割では対応不可能な新規のエントリの連鎖または連結リストが作成され得る（例えば第３種のＨＤＡＧノードを使用して）。例えば、図４８において、ノードへ「Ｔｏｍ」を挿入することが試行された時に、ノード４８５０は一杯になり、かつレベル数の上限に達した場合、「連鎖」という種類の新規ノードが、「Ｔｏｍ」のエントリを格納するために作成され、そして連鎖ノードを示すポインタが候補ノード内の選択された場所に挿入され得る。連鎖ノード自体は、必要があれば他の連鎖ノードを示すように変更可能である。連鎖ノード内に含まれている任意の所定のエントリの場所を特定するために、他の種類のノードにおいて使用されるハッシュベース検索の代わりに、連鎖の順次走査が使用され得る。このようにして、ＨＤＡＧが「不均衡」になっても多数のエントリが対応可能になるが、連鎖エントリは検索のために順次トラバースされる必要があり得るため、当然ハッシュベーストラバーサルの速さに関する利点のうちのいくつかは失われ得る。様々な実施形態において、適度に長いハッシュ値及び強力なハッシュ関数の選択により、連鎖ノードを使用しなければならない確率は、許容可能な閾値未満に低減され得る。

名前空間エントリＥを削除する時（例えばクライアントの要求で対応ファイルまたはディレクトリを削除した時）、前に略述された、オブジェクト名のハッシュ値のそれぞれのサブシーケンスがＨＤＡＧの連続レベルにおけるインデックスとして使用されるハッシュベーストラバーサル技術を使用して、エントリを削除する対象のＥＬノードが検出され得る。エントリを削除する対象のＥＬノードは、削除対象ノードと称され得る。削除対象が複数のエントリを含む場合、Ｅのエントリは単純に削除され得るか、空きと示され、追加動作を必要とし得ない。しかしながら、削除対象に他の名前空間エントリがない場合（すなわちＥのエントリを取り除くことで空のエントリリストができる場合）、その時は削除対象ノード自体が削除される必要があり得る。図４９は、少なくともいくつかの実施形態による、２種類のＨＤＡＧノード削除動作のうちの第１種のＨＤＡＧノード削除動作の例を示す。描かれた実施例において、ＨＤＡＧにより表現される名前空間から「Ｊｕｌｉｅｔ」を削除する要求が受信される。「Ｊｕｌｉｅｔ」のハッシュ値が計算され、そしてＨＤＡＧのルートからノード４９５０へ向かってナビゲートするのに、ハッシュ値の連続サブシーケンスが使用される。ノード４９５０は、１つだけ残ったエントリ（削除する「Ｊｕｌｉｅｔ」というエントリ）を有するＥＬノードである。Ｊｕｌｉｅｔというエントリが削除され得る（印「Ｘ」及び添付表示「１」により示されるように）。Ｊｕｌｉｅｔというエントリを取り除くことにより、ノード４９５０において空のエントリリストが生じるため、ノード４９５０自体が削除される必要があり得る。ノード４９５０を、その親ノード４９４８において削除することの結果は、ノード４９４８のＮＩアレイリストのステートにより異なり得る。

描かれた実施形態において、削除対象ノードの親ノードは一般に、削除対象ノードを示す１個または複数のＮＩアレイ要素（「削除対象ポインタ」と称され得る）と、削除対象ノード以外のノードを示す０個または複数のＮＩアレイ要素を有し得る。削除対象ノード以外のノードを示し、かつＮＩアレイ内で削除対象ポインタに隣接する（例えばアレイ内で削除対象ポインタのすぐ隣のより低いインデックスにおける）これらのＮＩアレイ要素は、削除対象ポインタの「隣接者」と称され得る。描かれた実施形態において、削除対象ノードの最後のエントリが削除された時に、４９４８のＮＩアレイリスト内に少なくとも１つの隣接者が存在する場合、隣接者ポインタ値が削除対象ポインタに単純にコピーされ得る。図４９において描かれるシナリオにおいて、例えば、親ノード４９４８内に、削除対象ノード４９５０を示す２つの削除対象ポインタ４９０１、４９０２が存在する（４９５０のＩＤ０ｘｃ４４３２１．．．が４９０１と４９０２に格納されている事実により示されるように）。また親ノード４９４８のＮＩアレイは、ノードＩＤ０ｘ３２１７６．．．を格納する隣接者要素４９０３を含む。従って、２と表示された矢印により示されるように、Ｊｕｌｉｅｔというエントリの削除により削除対象ノード４９５０において空のエントリリストが生じ、かつ親ノード４９４８が自身のＮＩアレイに少なくとも１つの隣接者を含む時、削除対象ノード４９５０を以前示していたＮＩアレイエントリに、隣接者のコンテンツがコピーされる。さらに、描かれた実施形態において、例えば格納サブシステムに対し削除対象ノード４９５０の格納領域を解放する要求を送信することにより、削除対象ノード４９５０は解放され得る。削除対象ポインタアレイ要素のコンテンツの、隣接者ポインタのコンテンツによる置き換えが、矢印４９０４により示される。異なる実施形態において、削除対象ポインタの隣接者を指定するのに異なる技術が使用され得ることに留意されたい。例えば、いくつかの実施形態においては、ＮＩアレイ内で削除対象ポインタの隣のより高いインデックスを有するＮＩアレイエントリが、隣接者として選択され得る。

いくつかの実施形態において、削除対象ノードの親ノードのＮＩアレイエントリに隣接者が存在しない場合、親ノードは別の方法で再編成され得る。図５０は、少なくともいくつかの実施形態による、２種類のＨＤＡＧノード削除動作のうちの第２種のＨＤＡＧノード削除動作の例を示す。示されるように、削除対象ノード４９５０は、自身のエントリリストに単一エントリを含む。印「Ｘ」及び添付表示「１」により示されるように、たった１つの残りのエントリ（「Ｊｕｌｉｅｔ」）が削除される。描かれた例示的シナリオにおいて、親ノード４９４８のＮＩアレイは、隣接者要素（すなわち削除対象ノードを示さないＮＩアレイ要素）を何も含まない。利用可能な隣接者ポインタ値が存在しないため、図４９において例示される手法は実行不可能であり得る。従って、「２」と表示された矢印により例示されるように、親ノード４９４８の種類はＮＩアレイの代わりにＥＬ（エントリリスト）に変更され、そして空のエントリリストはノード４９４８用に初期化され得るという別の手法が取られ得る。新規に初期化されたＥＬノードは、例えば前述の種々の分割動作の結果、ＨＤＡＧに新規ノードが追加される時に、再利用され得る。図４９に関して前述されたものと同様の方法で、削除対象ノード４９５０は解放され得る。様々な実施形態において、ＨＤＡＧの所定のレベルにおいて行われた変更は、いくつかの事例において他のレベルにおける変更を要し得る。例えば一実施形態において、ノード４８４８の種類が前述のように変更される時、４８４８の親ノードのＮＩアレイエントリは変更される必要があり、そして変更の結果はＨＤＡＧのルートへ向かって上向きに伝播し得る。先に述べたように、様々な実施形態において、前述の条件付き書き込み技術及び／または分散トランザクション技術は、所定の挿入または削除に起因する所望の数のＨＤＡＧ変更を、原子動作に合併するのに使用され得る。

図５１は、少なくともいくつかの実施形態による、第１種のＨＤＡＧノード分割を生じる名前空間へのエントリの挿入に応じて実行され得る動作の態様を例示するフロー図である。このような分割動作の簡潔な実施例が図４７に提供される。構成要素５１０１に示されるように、分散マルチテナント格納サービスの名前空間にエントリＥを追加する要求が受信される。例えば、サービスに実装されるファイルシステムのクライアントが出す、「Ｆｎａｍｅ」というファイルを作成する、または「Ｆｎａｍｅ」というファイルを開くという命令に応じて、要求は生成され得る。一実施形態において、要求は、特定のメタデータサブシステムノードにおける命令解釈コンポーネントにて生成され、別のメタデータサブシステムノード（または同一のメタデータサブシステムノード）における名前空間管理コンポーネントにて受信され得る。対象ファイルシステムの名前空間管理のために、ハッシュ関数が選択済みであり得る（例えばハッシュ関数の強度、ファイルストアの予想サイズ及び／またはパフォーマンス要件、並びに／あるいは別の要素に基づいて）。「Ｆｎａｍｅ」に対応するハッシュ値Ｈｖａｌｕｅを生成するために、ハッシュ関数が使用され得る。当該Ｈｖａｌｕｅは、それぞれＭビットのＮ個のサブシーケンスとして表現可能である（構成要素５１０４）。一実施態様において、例えば、Ｈｖａｌｕｅは、それぞれ８ビットの８個のサブシーケンスを有し、そのため少なくとも６４ビットを使用する。

少なくとも２つの種類のノード（前述のノード識別子アレイ（ＮＩアレイ）ノード及びエントリリスト（ＥＬ）ノード）を含むＨＤＡＧは、名前空間用に、例えば新規のファイルＦｎａｍｅを追加しているディレクトリ用に、設定され得た。描かれた実施形態において、エントリリストノードは、最大ＥＬエントリまで収容可能であり得る。当該最大ＥＬは、対応するオブジェクト名の最大長、エントリリストに格納されているＤＦＳ‐Ｉノードのアドレスまたは識別子の長さ、ＨＤＡＧノードに使用されているバイト数等の要素に依存し得る。同様に、描かれた実施形態において、ＮＩアレイは、ノードＩＤのサイズ及びＨＤＡＧノードのサイズに依存する最大ＮＩＤまで収容可能であり得る。少なくとも一実施形態において、挿入結果としてエントリ数がＥＬ閾値を超える場合にはノード分割を開始するように、エントリの保有数閾値であるＥＬ閾値が指定され得る。いくつかの実施態様において、ＥＬ閾値のデフォルト値は最大ＥＬに設定され、例えばＥＬが一杯になった時にのみ分割が実行され得る。同様に、少なくとも一実施形態において、ＮＩアレイノード用に閾値が定義され、例えばノードにおけるＮＩアレイ内の要素数がＮＩＤ閾値を超える時に、ＮＩアレイノードは分割され得る。いくつかの実施形態において、ＮＩＤ閾値は、デフォルトで最大ＥＬに設定され得る。いくつかの実施態様において、ＥＬ閾値、またはＮＩ閾値、あるいはＥＬ閾値とＮＩ閾値の両方が、設定可能なパラメータとして実施され得る。

Ｅが追加されるべき候補ノードＣＮを特定するために、各レベルにおいて検査する特定のノード（複数可）を同定するＨｖａｌｕｅの連続Ｍビットサブシーケンスを使用して、ＨＤＡＧのルート（ゼロ次レベル）から、１つまたは複数のＨＤＡＧレベルがナビゲートまたはトラバースされ得る（構成要素５１０７）。少なくともいくつかの実施形態において、ＨＤＡＧのそれぞれのノードは異なる論理ブロックに対応し、そして各ＨＤＡＧノードには、他のＨＤＡＧノードに使用されているものと異なる格納サブシステムノードにおける異なるエクステントが使用されている確率が高くあり得る。候補ノードが見つからない場合（いくつかの事例においてメタデータサブシステムにＨＤＡＧの領域がなくなった場合に起こり得る、構成要素５１１０にて検出）、エラー（例えば「ディレクトリの最大許容ファイル数を超えました」）が返され得る（構成要素５１１３）。候補ノードＣＮが見つかり（同様に構成要素５１１０にて検出）、かつそのエントリリストが新規エントリＥを収容するのに十分な領域を有する（例えばＥの追加が原因で、ＥＬの長さがＥＬ閾値を超えることはない）場合（構成要素５１１６にて検出）、新規エントリＥは、リスト内の現在未使用のエントリのうちの１つに書き込まれ得る（構成要素５１１９）。ＣＮに対する変更は、描かれた実施形態において、永続性格納領域に、例えば１つまたは複数のメタデータエクステントレプリカにて、保存され得る。少なくともいくつかの実施形態において、ＤＦＳ‐Ｉノード構造は、名前Ｆｎａｍｅを有するオブジェクトに割り当てられ、そしてＤＦＳ‐Ｉノード構造を示すポインタはＥ内に含まれ得る。「Ｆｎａｍｅ」の後続検索要求に応じて、構成要素５１０４と５１０７に例示されるものと同様のハッシュベースナビゲーションが使用され得る（すなわち、「Ｆｎａｍｅ」のエントリが見つかるまで、「Ｆｎａｍｅ」に取得されたハッシュ値のそれぞれのサブシーケンスが、ＨＤＡＧのそれぞれのレベルのナビゲーションに使用され得る）。

ＣＮがＥに対し十分な領域を有さない場合（例えばＥＬ閾値に既に達した、またはＥの挿入により達し得る場合）（同様に構成要素５１１６にて検出）、ＣＮの親ＮＩアレイリスト内のＣＮを示すポインタ数が特定され得る。親ノードがＣＮのポインタを１つのみ有する（または図らずもＨＤＡＧのルートノードである）場合（構成要素５１２２にて検出）、第１種の分割動作（図４７に例示されるものと同様）が開始され得る。新規エントリＥに対し既にハッシュ値Ｈｖａｌｕｅが取得されたのに加え、ＣＮリスト内のそれぞれのエントリにおけるオブジェクト名に対し、それぞれのハッシュ値が取得され得る（構成要素５１２５）。描かれた実施形態において、エントリリストのメンバー及びＥを、Ｐグループに分散するのにハッシュ値が使用され（構成要素５１２８）、例えばハッシュ値のｌｏｇ₂Ｐ最上位ビットが並び替え／分散基準として使用され得る。一例示的実施態様において、Ｐは２に設定され、そのため単一最上位ビットが使用され得る。それぞれのＰグループは、ＨＤＡＧに追加するそれぞれの新規ノードのエントリリストとして格納され得る（構成要素５１３１）。Ｐ個の新規ノードそれぞれを示す（例えばＰ個の新規ノードそれぞれの格納アドレスまたは識別子を含む）アレイ要素のうちの約Ｐ分の１のアレイ要素を有する新規ＮＩアレイが作成され得る。ＣＮのヘッダーは、ＣＮはＥＬノードではなくＮＩアレイノードであることを示すように変更され、そして新規ＮＩアレイがＣＮに書き込まれ得る（構成要素５１３４）。ＨＤＡＧのＰ個の新規ノードのコンテンツ及び変更されたＣＮは、永続性格納領域に、例えば１つまたは複数の格納サブシステムノードにて、保存され得る。いくつかの実施形態において、ＨＤＡＧに対する変更のある部分集合または全てを単一の原子動作に合併するために、前述の分散トランザクション技術が使用され得る。別の実施形態において、前述の種類の条件付き書き込みは、ＨＤＡＧノードのうちの少なくともいくつかに使用され得る。

ＣＮの親ノードからＣＮを示しているＮＩアレイ要素の数が複数である場合（同様に構成要素５１２２にて検出）、ＣＮに対し第２種の分割動作が行われ得る（図５１の構成要素「５２０１へ進む」により示されるように）。図５２は、少なくともいくつかの実施形態による、このような第２種のＨＤＡＧノード分割を生じる名前空間へのエントリの挿入に応じて実行され得る動作の態様を例示するフロー図である。このような種類の分割は、本明細書において第２種分割と指定され、そして図５１において例示される種類の分割は、第１種分割と称され得る。第２種分割において、ＣＮエントリリストのメンバーのうちのいくつかはＱ個のＨＤＡＧの新規ＥＬノードへ移動され（Ｑは１以上）、同時にいくつかはＣＮ内に残り、そして親ノードのＮＩアレイポインタは適宜変更され得る。描かれた実施形態において、Ｑ個のＨＤＡＧの新規ノードＮＮ１、ＮＮ２、・・・ＮＮＱ間及びＣＮ自体における再分散のために、ＣＮエントリリストのサブリストが選択され得る。一実施態様において、Ｑは１に設定され、エントリリストの約半分（または正確に半分）が再分散の対象となり、一方別の実施態様においては、エントリリストの４分の３が再分散の対象となり得る。サブリストのメンバーごとに、それぞれのハッシュ値が決定され得る（構成要素５２０４）。サブリストのメンバーをＱ＋１グループに配置するのにハッシュ値が使用され（構成要素５２０７）、例えばハッシュ値の最上位ビットのうちのある数が分散基準として使用され得る。

Ｑ個のグループが、それぞれのＨＤＡＧの新規ＥＬノードに配置され、一方残りのグループはＣＮ内に保持され得る。ＣＮを示していたＣＮの親ノード内のＮＩアレイエントリのうちのいくつかは、新規ノードＮＮ１、・・・、ＮＮＱを示すように設定され得る（構成要素５２１０）。描かれた実施形態において、分割の結果、変更または作成されたＨＤＡＧノード（例えばＱ個の新規ノード、ＣＮ、及びＣＮの親ノード）は、単一原子動作において、永続性格納領域に書き込まれ得る（構成要素５２１３）。いくつかの実施形態において、前述の分散トランザクション技術が使用され得る。別の実施形態において、単一原子動作は使用され得ない。例えば、条件付き書き込み技術が、ＨＤＡＧノードのうちの少なくともいくつかに使用され得る。

いくつかの実施形態において、エントリリストのメンバーが第２種分割で再分散される技術は、図５２において例示されるものと異なり得ることに留意されたい。例えば、いくつかの実施形態において、サブリストのメンバーは、Ｑ個の新規ノード間に全て分散され得るように選択され得る。いくつかの実施形態において、サブリストのサイズは、ランダムに選ばれ得る。例えば、所定のＨＤＡＧまたは所定のファイルストアにおいて実行される全ての第２種分割が、同じ数の新規ノードを生じ得るとは限らない。いくつかの実施形態において、ランダム性の要素が第１種分割にも導入され得る。例えば、使用されるＥＬ閾値は範囲内でランダムに変更され得る、または新規ノードＰの数は範囲からランダムに選択され得る。

図５３は、少なくともいくつかの実施形態による、名前空間からエントリの削除に応じて実行され得る動作の態様を例示するフロー図である。構成要素５３０１に示されるように、分散格納サービスの名前空間から、名前Ｆｎａｍｅを有するファイルストアオブジェクトのエントリＥを削除する要求が受信され得る。このような要求は、例えばファイルまたはディレクトリを削除するクライアント要求の結果、生成され得る。選択されたハッシュ関数を使用して、それぞれＭビットのＮ個のサブシーケンスに分割可能なビットシーケンスを有するハッシュ値Ｈｖａｌｕｅが取得され得る（構成要素５３０４）。

Ｅを含む削除対象ノードＮ１を特定するために、名前空間のために生成されたＨＤＡＧは、そのルートノードからナビゲートまたはトラバースされ得る（構成要素５３０７）。ＨＤＡＧの各レベルにおいて、読み出しまたは検査対象のノードを特定するのに、Ｎ個のサブシーケンスのうち連続サブシーケンスが使用され得る。Ｎ１のエントリリストが少なくとももう１つのエントリを含む場合（構成要素５３１０にて検出）、エントリリスト内のＥのスロットは単純に未使用または空と示され（構成要素５３１３）、そして削除動作は完了し得る。いくつかの実施態様において、例えば空でないエントリを早く見つけるために、解放されたエントリはリストの一端へ移動され得る。従って、例えば、長さＮのエントリリストが２つの空でないエントリを含む場合、このような一実施態様において、これらの２つの空でないエントリは、リスト内のオフセット０及びオフセット１において検出され、一方でオフセット２、３、・・・、Ｎ−１のエントリは空であり得る。いくつかの実施形態において、Ｎ１に対する変更は、Ｅの削除要求と同期的に永続化され、一方で別の実施形態において、Ｎ１は、Ｅの削除要求と非同期的に１つまたは複数のエクステントにおける永続性格納領域に書き込まれ得る。

ＥがＮ１のエントリリスト内の最後のエントリである場合（同様に構成要素５３１０にて検出）、Ｎ１の親ノードＰＮのＮＩアレイが検査され得る。ＰＮのＮＩアレイは、Ｎ１を示す（例えばＮ１のアドレスまたは識別子を格納する）１つまたは複数の要素ＮＰ１、ＮＰ２、・・・、を含み得る。ＰＮのＮＩアレイが、Ｎ１以外のあるノードを示す少なくとも１つの「隣接者」要素ＮＸも含む場合（構成要素５３１６にて特定）、ＮＸのコンテンツはＮＰ１、ＮＰ２、・・・へコピーされ、そのためＰＮはＮ１を示すポインタを含まなくなる（構成要素５３１９）。少なくともいくつかの実施形態において、アレイ要素ＮＰ１、ＮＰ２、・・・が、同様にまたは代わりに無効と示され得る。

ＰＮのＮＩアレイがＮ１以外のノードを示す隣接者要素を含まない場合（同様に構成要素５３１６にて検出）、描かれた実施形態において、ＰＮは別の方法で変更され得る。構成要素５３２２に示されるように、ＰＮの種類が、例えばそのヘッダーを変更することで、ＮＩアレイからＥＬへ変更され得る。さらに、ＰＮ用に新規のエントリリストが初期化され得る。例えばＮＩアレイに使用されていたバイトのうちの少なくともいくつかは上書きされ得る。描かれた実施形態において、親ノードＰＮ内に隣接者要素が見つかったか否かに関係なく、削除対象ノードは空または未使用と示され得る（構成要素５３２５）。例えばＰＮ及びＮ１といった削除の影響を受けるそれぞれのノードのコンテンツは、格納サブシステムの１つまたは複数のエクステントにおける永続性格納領域に保存され得る。いくつかの実施形態において、少なくとも構成要素５３２２、５３２５に示される変更を単一原子動作の一環とするために、前述の種類の分散トランザクションが使用され得る。別の実施形態において、構成要素５３１９に示される変更も、構成要素５３２２、５３２５の変更と共に、単一原子動作または分散トランザクションに合併され得る。少なくとも一実施形態において、それぞれの変更に、条件付き書き込みが使用され得る。

様々な実施形態において、ハッシュベースの名前空間管理技術の様々な態様を特定するために、設定可能パラメータ（例えばファイルシステムレベルで、またはファイル格納サービス全体として定義される）が使用され得る。このような設定可能パラメータは、（ａ）使用する特定のハッシュ関数（複数可）またはハッシュ関数族、（ｂ）ハッシュ関数により出力されるビットシーケンスの要求される長さ、（ｃ）ＤＡＧのそれぞれのレベルをトラバースするために使用する出力されたハッシュ値の様々なサブシーケンスの長さ、（ｄ）各種分割の論理出力数（例えば各種分割において、分割ノードのエントリを割り当てるリストの数）、（ｅ）分割後に各新規ノードの識別子を格納するＮＩアレイ要素の数（または分数）、（ｆ）各種分割の保有レベル閾値、（ｇ）ＤＡＧの最大許容レベル数またはＤＡＧの合計サイズ、以上の任意の組み合わせのため特定され得る。いくつかの実施形態において、パラメータにより追加制約（例えばエクステント配置制約）も特定され得る。例えば、最初のＮレベルの全てのＨＤＡＧノードは同一のエクステントに格納されるという制約が特定され得る、あるいはどの２つのＨＤＡＧノードも同一のエクステントに格納されるべきではないという制約が特定され得る。いくつかの実施形態において、これらのパラメータのうちの１つまたは複数は、収集されたパフォーマンス結果に基づいて、変更され得る。例えば、特定のファイルシステムに対する所定のパラメータの集合では、名前空間関連パフォーマンスが不十分である場合、同一のファイルシステム（オンザフライで、または再構成ダウンタイム期間中に、新規ＨＤＡＧを作成することを伴い得る）のために、または後に作成されるファイルシステムのために、格納サービスはパラメータを調整し得る。

クライアントセッションメタデータ管理
少なくともいくつかの実施形態において、分散格納サービスは、ＮＦＳ等の１つまたは複数のステートフルまたはセッション指向のファイルシステムプロトコルに対応し得る。いくつかのこのようなプロトコルにおいて、サービスのクライアントコンポーネント（例えばクライアント側実行プラットフォームにおいて稼働しているデーモン）は通常、サーバコンポーネント（例えばサーバ側実行プラットフォームにおいて稼働している別のデーモン）との１つまたは複数の通信を介してセッションを作成し得る。当該セッションは関連有効時間を有し、その間サービスはある種類のクライアント要求に対する応答を早めることが可能となり、そして当該セッションはいくつかの条件の下、延長または更新することが可能である。セッション中、クライアントは、例えばファイル等のオブジェクトに対するロックを確保し、そしてロックは、セッションが終わるか、クライアントがロックを解放するまで、有効なままであり得る。セッション中、クライアントからのオブジェクトに対する後続アクセスは、追加ロックを要し得ない。いくつかのファイルシステムプロトコルによれば、このようなサーバからクライアントに対するファイル（または別の種類のファイルストアオブジェクト）のステート制御の時間制限付き授与は、「リース」と称され得る。単一リースは、複数のファイルストアオブジェクトに対するロックを伴い、そしてクライアントにより明示的または非明示的に更新され得る。少なくともいくつかの実施形態において、セッション指向プロトコルは、セッションステート情報（例えばクライアントのリースに対応付けられたロックされたファイルまたはディレクトリのリスト、リースの有効時間等）が「ファイルサーバ」により保持されることを要求し得る。分散ファイル格納サービスにおいて、プロトコルが命令するファイルサーバの責務は、例えばアクセスサブシステム、メタデータサブシステム、及び／または格納サブシステム等、前述の様々なサブシステム間に分散され得る。プロトコルが命令するセッション関連機能のうち、異なる実施形態の異なるサブシステムにおいて実行されるべき特定部分を決定する際、測定可能応答時間と処理量目標、メタデータ耐久性要件等の様々な要素が考慮され得る。

図５４は、少なくともいくつかの実施形態による、分散格納サービスにおけるセッション指向のファイルシステムプロトコルのために保持され得るメタデータの二局面を例示する。所定のクライアントセッション中に開かれている及び／またはロックされている全てのオブジェクトに関する情報は、ある種の動作のために（例えばセッションの全てのロックを解放するよう要求し得るリース期限切れのために）、格納サービスにより効率的にアクセスされる必要があり得る。メタデータ情報のこの第１局面は、クライアントセッションＣＳ１に関するリース関連動作のためにアクセスされ得るメタデータ集合５４０１のコンテンツ等、示される概念的メタデータテーブル５４０１における行により表される。メタデータ集合５４０１は、例えば、ロックステートインジケータ（ＬＳＩ）（ＮＦＳ「ステートＩＤ」等）を含み、複数のファイル、ディレクトリ、リンク等に対するロックステートインジケータの使用方法は、さらに詳しく後述される。示される実施例において、クライアントセッションＣＳ１に関しては、書き込みロックステートインジケータＷロックがディレクトリＤ１に示され、そしてＲロック（読み出しロックインジケータ）がファイルＦ１、ＦＰに示される。少なくともいくつかの実施態様において、ロックはファイルレベルで実行され、ディレクトリレベルでは実行され得ないことに留意されたい。

第２局面は、ファイルＦ１に関するメタデータ集合５４２０等、任意の所定オブジェクトに対するファイルシステムプロトコルに従って保持される必要のあるセッション関連情報の集合である。このメタデータの第２集合（同様にクライアントセッションＣＳ１のＲロック等のロックステートインジケータを含み得る）は、例えばオブジェクトをロックする新規の要求が受信された時、またはオブジェクトのステートまたは属性を見る要求が受信された時、効率的にアクセスされる必要があり得る。数百万のオブジェクト（そのうちの多数は複数のエクステントにわたって少なくとも潜在的に分散される）を格納し、多数の異なる種類の対応されているロックモード及び／またはリースモードの数万の同時クライアントセッションを有し得るファイルストアにおいて、図５４において例示される種類のセッション関連情報全てを単一集中場所に格納することは、実践的または効率的ではあり得ない。図５４は従って、様々な実施形態において、効率的にアクセスされる必要があり得る少なくとも２つの種類のセッション関連メタデータの概念的観点を提供し、いずれの特定の実行手法を意味する意図はない。

特定のファイルシステムプロトコルが要求するセッション指向メタデータ５４０１に加えて、他の内部メタデータ（前述のＨＤＡＧを含む名前管理メタデータ、前述の論理ブロック対物理ページマッピング等）も保持され得ることに留意されたい。少なくともいくつかの実施形態において、異なる種類のメタデータがメタデータサブシステムの独立サブコンポーネントにより管理され得る。例えばストライピングまたは論理ブロック対物理ページマッピングの管理が、図５４において例示される種類のクライアントセッション情報の管理とは無関係に実行され得る。さらに分散格納サービスは、少なくとも一実施形態において、複数のステートフルまたはセッション指向のファイルシステムプロトコルに対応し、それぞれのステートフルまたはセッション指向のファイルシステムプロトコルは、それぞれのセッションメタデータオブジェクトの種類及びセマンティックを定義し得る。例えば、ＮＦＳはそのメタデータオブジェクトの集合及び関係を特定し得る、ＳＭＢは別の集合を特定し得る、等が挙げられる。このようなシナリオにおいて、それぞれの異なるプロトコルに対応付けられたファイルシステムのために、セッション指向メタデータ５４０１の個別集合が保持され得る。

少なくともいくつかの実施形態において、クライアント（プロバイダネットワークの演算インスタンスにおける１つまたは複数のプロセスを使用して実行されるＮＦＳクライアント等）は、分散格納サービスに対しファイルシステムプロトコルに従ってフォーマットされたメッセージを送信することで、クライアントセッションの確立を要求し得る。図５５は、少なくともいくつかの実施形態による、分散格納サービスのサブコンポーネント間におけるクライアントセッションのメタデータ関連インタラクションの例を示す。ファイルシステムクライアント５５０１は、例えばクライアントが使用しているファイルシステムのエンドポイントとしてＩＰアドレスが公開または公表されているアクセスサブシステムノードといった、アクセスサブシステムノード５５１２に対し、セッション要求５５５０を送信し得る。使用されているファイルシステムプロトコルがＮＦＳであるいくつかの実施態様において、例えば、セッション要求は、「クライアントＩＤ設定」要求を有し、かつクライアントの識別（クライアントにより生成）と「ベリファイア」と呼ばれる一意的で繰り返しのないオブジェクト（同様にクライアントにより生成）とを含み得る。いくつかのこのような実施態様において、セッションが最初に開始されてからクライアントはリブートされたか否かを特定するために、ベリファイアがサービスにより使用され得る。従って、別のベリファイアを有する第２のクライアントＩＤ設定要求の送信により、サービスはクライアントの前のセッション／リースを終了することが可能になり得る。セッション要求に応じて、使用されているファイルシステムプロトコルは、セッション識別子５５６３（例えばＮＦＳ「クライアントＩＤ」オブジェクト）がサービスにより最終的に要求者に提供されることを要求し得る（エラー状態に遭遇しない限り）。

少なくともいくつかの実施形態において、分散格納サービスのメタデータサブシステムは、クライアントセッションステート情報を管理する責任を担い得る。例えば、メタデータサブシステムは、クライアントセッションステート情報が論理ブロックにマッピングされる方法を、これら論理ブロックのエクステントに対するマッピングと同様に、制御し得る。前述のように、エクステント自体は、いくつかの実施形態においては格納サブシステムノードに格納され、そして別の実施形態においては、メタデータサブシステムノードに格納され得る。いくつかの実施形態において、アクセスサブシステムノードは、セッション関連メタデータを一時的にキャッシュし得る一方、メタデータサブシステムは、分散格納サービス内のクライアントセッション情報の権限を有する発信元として指定され得る。

描かれた実施形態において、クライアントセッション要求を受信した際、アクセスサブシステムノード５５１２は、セッション識別子がメタデータサブシステムにより生成されることを求めるセッション初期化要求５５５３を、選択されたメタデータノード５５２２へ送信し得る。少なくともいくつかの実施形態において、クライアントにより提供されるパラメータ（例えばクライアントの識別子及び／またはベリファイア）は、アクセスノードによりメタデータノードへ伝達され得る。メタデータノード５５２２は、新規の論理ブロックＬＢ１を生成し、クライアントのセッションメタデータの少なくとも一部を格納する。描かれた実施形態において、ＬＢ１は例えば、メタデータによりクライアントセッションのために生成されるセッション識別子５５６３と、セッションのリースタイムアウト設定５５４４と、「責任アクセスノード」（ＲＡＮ）フィールド５５４６とを含み得る。ＲＡＮフィールドは、特定のアクセスノード５５１２を特定し、後続のセッション中のクライアント要求は、当該アクセスノード５５１２を介して、バックエンドサブシステム（例えばメタデータサブシステムまたは格納サブシステム）において受信されると見込まれる。描かれた実施形態において、矢印５５５７により示されるように、メタデータノード５５２２は、セッションメタデータの論理ブロックのコンテンツを、選択されたエクステント５５８０の１つまたは複数のページに格納する。いくつかの実施態様において、メタデータノード５５２２は、格納サブシステムに対し論理ブロックコンテンツを格納する要求を送り、一方他の実施形態において、メタデータノード５５２２は、メタデータサブシステム自身が管理するエクステントに当該コンテンツを書き込み得る。

少なくともいくつかの実施形態によれば、クライアントのために選択または生成されるセッション識別子（例えばＮＦＳクライアントＩＤ）は、論理ブロックの格納アドレスに少なくとも一部基づき得る。例えばセッション識別子は、読み出し動作において、クライアントセッションメタデータを早く検索するためのパラメータとして後で使用され得る。例えば、一実施態様において、各論理ブロックに１２８ビットの論理格納アドレスが割り当てられ、そしてＬＢ１に使用される１２８ビットの論理アドレスは、セッション識別子５５６３としてクライアントに提供され得る、またはセッション識別子５５６３内に含まれ得る、もしくは符号化され得る。別の実施形態において、セッション識別子は、セッションメタデータ要素を格納するために使用されている物理ブロック（複数可）のうちの少なくとも１つの物理格納アドレスに少なくとも一部基づき得る。メタデータノード５５２２は、セッション初期化要求５５５３に対する応答５５６０を送信し得る。描かれた実施形態において、応答５５６０は、アクセスノード５５１２のキャッシュ５５７８にキャッシュされ、かつ要求クライアント５５０２に提供され得るセッション識別子５５６３を含み得る。いくつかの実施形態において、ファイルシステムのセッション確立プロトコルは、１つまたは複数の追加インタラクションを要求し得る。例えば、セッション識別子を含む確認要求メッセージがクライアント５５０２により格納サービスへ送信され、それからクライアントはセッション識別子の有効性を確認する応答を受信し得る。少なくともいくつかの実施形態において、ファイルオープン、クローズ、ロック要求等のクライアントからの後続要求は、セッション識別子５５６３を含むように要求され得る。このような後者の要求を受信した際、アクセスノード５５１２は、キャッシュ５５７８を使用してクライアントのセッション識別子を有効化し得る。セッション識別子がキャッシュにない場合、アクセスノードはメタデータサブシステムに対しセッションに関するクエリを送り、セッションがまだ開いている場合は（またはクエリに応じてメタデータサブシステムにより新たなセッションがインスタンス化される場合は）、要求された動作のみを続行し得る。

前に示されたように、いくつかの実施形態において、ＮＦＳ等のファイルシステムプロトコルは、ファイルシステムオブジェクトに対する同時アクセスを効率的に管理するリース技術を実行し得る。いくつかのこのような実施形態において、クライアントセッションに対応付けられるリースは、クライアントに対するファイルシステムの１つまたは複数のファイル、ディレクトリ、リンク、または他のクライアントアクセス可能オブジェクトのステート制御の時間制限付き授与を表し得る。少なくとも一実施形態において、格納サービスによる特定のファイルシステムオブジェクトのロックステートを表すのに、本明細書においてロックステートインジケータと称される別のメタデータオブジェクトが使用され得る。例えば、ＮＦＳプロトコルの少なくともいくつかの実施態様において、ロックステートインジケータは「ステートＩＤ」と称され得る。ファイルＦ１等のオブジェクトのロックステートインジケータは、少なくともいくつかの実施形態において、所定のクライアントセッションＣＳに照らして定義され得る。従って、例えば、クライアントＣｌ１がクライアントセッションＣＳ１の一環でファイルＦ１をロックすると、ＣＳ１に特有のＦ１のロックステートインジケータＬＳＩ１が作成され得る。そしてその後、別のクライアントＣｌ２がクライアントセッションＣＳ２の一環でファイルＦ１をロックすると、別のロックステートインジケータＬＳＩ１が格納サービスにより生成され得る。少なくともいくつかの実施形態において、ＬＳＩは、該当クライアントセッションのセッション識別子を示すポインタを組み込み得る、または含み得る。例えば、一実施態様において、ＮＦＳ対応ステートＩＤは、該当クライアントＩＤを示すポインタ（または該当クライアントＩＤの実際の値）を含み得る。各オープンクライアントセッションは、いくつかの実施形態において、対応リースタイムアウト時間を有し、当該対応リースタイムアウト時間の終わりには、セッションの全てのＬＳＩに対応付けられたロックが解放され得る。いくつかの実施形態において、特定のファイルストアオブジェクトはクライアントによるアクセスのため現在開いた状態であることを示すのに、オープンステートインジケータ（ＬＳＩと同様）が使用され得る。いくつかの実施態様において、ファイルストアオブジェクトのオープンステート及びロックステートの開示は、単一メタデータ構造（例えばオープン／ロックステートインジケータ）を使用して表され得る。

リースを実行する少なくともいくつかのファイルシステムプロトコルのセマンティックによれば、１つまたは複数のリース更新機構が対応され得る。例えば、動作種類の集合が定義され、これによりオープンセッション中のクライアントによるその動作種類集合の動作の要求は、自動的にリースを、ある特定されたリース更新期間に更新することになり得る。このような実施形態において、クライアントがファイルＦ１を読む要求を出した場合、例えば、リースが時間Ｔ１に失効するように設定されたセッションＣＳ１中に、リースはさらに後の時間Ｔ２に延長され得る。いくつかの実施形態において、明示的にリースを更新するＡＰＩが、同様にまたは代わりに対応され得る。自動的（または明示的）リース更新に至る種類の要求が、特定の期間に全く受信されなかった場合、リースは失効し得る。いくつかの実施形態において、リース失効の際、対応ロック（ＬＳＩにより示される）は格納サービスにより解放され、セッション中に開かれ、かつリース失効時点以前に閉じられていなかったファイルシステムオブジェクトが閉じられ、そして少なくともいくつかの実施形態において、メタデータサブシステムの永続性レポジトリから、及び／またはアクセスサブシステムのキャッシュから、セッションメタデータが削除され得る。

図５６は、少なくともいくつかの実施形態による、分散格納サービスにおけるクライアントセッションのリース更新の代替的手法を例示する。描かれた実施形態において、自動更新動作リスト５６７８は、クライアントにより使用されているファイルシステムプロトコルにより特定され得る。自動更新動作リスト５６７８は、現在開かれているセッション中に要求されると、セッションに対応付けられたリース（複数可）の自動更新に至る動作種類を示し得る。例えば、いくつかのＮＦＳ実施態様において、自動更新動作リストは、（数ある中でも）読み出し、書き込み、オープン、ロック、ロック解除、及び属性設定動作を含み得る。いくつかの実施態様において、リースの明示的更新に関する更新動作も、動作リスト５６７８に含まれ得る。

描かれた実施形態において、アクセスサブシステムノード５５１２は、ファイルストア動作要求５６５０を受信し得る。動作要求が自動更新動作リストに示される種類の動作である（またはクライアントのリースを更新する明示的要求である）場合、描かれた実施形態において、アクセスノード５６１２は２つの選択肢を有し得る。アクセスノードは、即時すなわち非バッチリース更新要求５６５３をメタデータノード５５２２に送り得るか、またはある設定可能な時間が経つまでリース更新を延期し、バッチリース更新要求５６５４をメタデータノード５５２２に送り得る。バッチリース更新要求は、例えば自動更新動作要求または明示的更新要求が時間窓内に受信された複数のクライアントセッションのセッション識別子を含み得る。少なくともいくつかの実施形態において、リース更新要求のバッチ化は、メタデータノード５５２２及び／またはアクセスノード５５１２における更新関連オーバーヘッド（例えば通信オーバーヘッド、処理オーバーヘッド、またはその両方）を軽減するのに役立ち得る。

いくつかの実施形態において、クライアントの動作要求５６５０に応じて所定のリース更新はすぐに送信されるべきか否か、またはクライアントのリース更新に延期バッチ手法は使用されるべきか否かを決定するために、設定可能即時更新閾値５６８８がアクセスノードにより使用され得る。例えば、即時更新閾値がＸ秒に設定され、かつクライアントのリースはアクセスノードが動作要求５６５０を受信した時間からＸ秒内に失効するように設定されている場合、非バッチすなわち即時リース更新要求５６５３が、描かれた実施形態において生成され得る。そうでなく、リースが失効するように設定された時間までＸ秒を超える時間が残っている場合、クライアントの更新要求の表現はバッチ更新バッファ５６７９に格納され、そしてある数の更新がバッチリース更新要求５６５４としてメタデータノード５５２２へ後で送信され得る。描かれた実施形態において、アクセスノードは、セッションメタデータキャッシュ５５７８内に、アクセスノードが責任を持つ様々なクライアントセッションのリース有効時間をキャッシュしており、キャッシュコンテンツを使用して、即時更新要求を送信するか、バッチ更新要求を送信するかに関して決定し得る。リース更新とは無関係に、アクセスノードは、クライアントのために要求された動作を開始し（例えばキャッシュされたクライアントセッションメタデータ、及び／またはキャッシュされた論理ブロック対物理ページマッピングを使用して）、適切なファイルストア動作応答５６６３をクライアント５５０２に提供し得る。

所望するパフォーマンスレベルで様々な種類のファイルストア動作を実行するために、ファイルストアオブジェクトのロックステート情報の格納に関するいくつかの手法のうちのいずれかが採用され得る。図５７ａ及び５７ｂは、少なくともいくつかの実施形態による、分散格納サービスにおけるセッション指向のファイルシステムプロトコルのためのロックステート管理の代替的手法を例示する。図５７ａに例示される一手法において、特定ファイルシステムのロックステートインジケータ５７０５は、複数のエクステント間に分散され得る。当手法のいくつかの実施態様において、様々なファイルストアオブジェクトのロック及び／またはオープンステート情報を含むＬＳＩは、例えば対応名前空間ＤＦＳディレクトリエントリ（名前空間エントリ）、ＤＦＳ‐Ｉノード、及び／またはファイルシステムのオブジェクトの論理ブロック対物理ページマッピングといった、エントリのために保持される他の種類のメタデータと一緒に格納され得る。従って、例えば、ルートディレクトリのＬＳＩ５７０５Ａはルートディレクトリの他のメタデータ５７０４Ａと一緒に特定のエクステントの１つまたは複数の論理ブロックに格納され得る、ディレクトリＤ１のＬＳＩ５７０５ＢはディレクトリＤ１の他のメタデータ５７０４Ｂと一緒に別のエクステントに格納され得る、等が挙げられる。同様に、それぞれのオープン／ロックステート情報エントリ５７０５Ｃ、５７０５Ｄ、５７０５Ｅ、５７０５Ｆはそれぞれ、ディレクトリＤ２、ディレクトリＤ３、ファイルＦ１、ファイルＦ２のそれぞれの論理ブロックに格納され得る。図５７ｂに例示される第２のアプローチにおいて、所定のファイルシステムの全てのオブジェクトに関するオープン／ロックステート情報は、例えば単一メタデータエクステント５７５４内に、統合された形で格納され得る。例えばセッション無効化動作のため、所定のクライアントセッションに関する全てのＬＳＩエントリを検索する時、図５７ａに例示される分散手法が使用される場合は複数のエクステントがアクセスされ、一方図５７ｂに例示される統合手法が使用される場合は１つまたは少数のエクステントのみが要求され得る。しかしながら、ある状況下では、統合手法は、例えば保有ファイルストアオブジェクトが変わりＬＳＩが削除され得るため、及び／または所定のファイルシステムのロック／オープンステート情報に最終的に必要となる格納量は、ファイルシステムが作成され、かつそのＬＳＩのエクステントが取得された時に予測することが容易ではあり得ないため、分散手法よりも劣ったリソース使用という結果をもたらし得る。

図５８は、少なくともいくつかの実施形態による、分散格納サービスにおいて実行され得るクライアントセッションメタデータ管理動作の態様を例示するフロー図である。構成要素５８０１に示されるように、クライアントからクライアントセッションを開始または作成する要求が、ＮＦＳまたはＳＭＢ等のステートフルまたはセッション指向のファイルシステムプロトコルに対応する分散格納サービスのアクセスサブシステムノードにおいて受信され得る。いくつかの実施態様において、ＮＦＳクライアントＩＤ設定ＡＰＩと同様の明示的セッション初期化を要求するＡＰＩが、クライアントにより使用され得る。別の実施態様において、セッションを確立する要求は非明示的であり、例えばクライアントにより呼び出されたオープン（）ＡＰＩに対してセッションが既に存在しない場合に、セッションが初期化され得る。いくつかの実施態様において、セッション要求は、特定クライアントの識別（例えば１つまたは複数のクライアントプロセスが実行されているホストのＩＰアドレス及び／またはホスト名に由来する値）、並びに一意的使い捨てベリファイア値を含み得る。クライアントプロセスが終了し、再開される必要がある場合、またはクライアントプロセスが実行されるホストまたは演算インスタンスがリブートされる場合、少なくともいくつかの実施形態において、新たなセッションが初期化される必要があり、そして対応セッション初期化要求において、別のベリファイアが格納サービスに提供され得る。

描かれた実施形態において、分散格納サービスのメタデータサブシステムは、１つまたは複数のエクステントにおける永続性格納領域にクライアントセッション情報を格納する責任を担い、一方アクセスサブシステムは、例えばアクセスノードの揮発性メモリ及び／またはローカル永続性格納領域にセッションステート情報をキャッシュするように構成され得る。セッション要求を受信することに応じて、アクセスノードはセッション識別子の要求を、例えば内部バージョンのクライアントのセッション要求として、選択されたメタデータノードへ送信し得る（構成要素５８０４）。いくつかの実施形態において、メタデータノードは、クライアントの識別情報に基づいて選択され得る。例えば、一実施形態において、クライアントＣｌ１、Ｃｌ２のために確立するそれぞれのクライアントセッション用に、２つの異なるメタデータノードＭＮ１、ＭＮ２が選択され得る。選択されたメタデータノードは、例えばセッションのリース設定、クライアントの識別、クライアントセッションの責任アクセスノードの識別等を含む格納するクライアントセッションメタデータの様々な要素に、論理ブロック（前述のマッピング技術のうちの１つを使用して、メタデータエクステントにおける複数の物理ページにマッピングされる）を割り当て得る（構成要素５８０７）。少なくともいくつかの実施形態において、セッションメタデータが格納されるアドレスに少なくとも一部基づいて、セッション識別子（例えばＮＦＳクライアントＩＤ）が新たなセッションのために決定され得る。例えば、論理ブロックアドレスまたは物理ページアドレスは、セッション識別子内に組み込まれ得る、またはセッション識別子として使用され得る。描かれた実施形態において、セッション識別子及び初期リース設定が、メタデータノードからアクセスノードへ提供され得る（構成要素５８１０）。いくつかの実施形態において、セッション識別子のみがアクセスノードへ提供され、そしてアクセスノードは、セッション識別子の少なくとも一部を読み出し要求におけるパラメータとして使用して、格納サブシステムからセッションメタデータの他の要素を取得することが可能であり得る。

セッション識別子及びリース情報は、アクセスノードによりセッションメタデータキャッシュにキャッシュされ、そしてセッション識別子がクライアントへ返され得る（構成要素５８１３）。クライアントは、セッション識別子をパラメータとして、後続ファイルストア動作要求に、例えばファイルシステムのファイルまたはディレクトリに対するオープン（）、読み出し（）、書き込み（）、属性取得（）、またはクローズ（）コールに、含め得る。アクセスノードがこのような動作要求を受信すると、例えばクライアントのセッションがまだ開いているかを確かめるために、自身のローカルキャッシュ内においてセッション情報を検索し得る。

描かれた実施形態において、使用されているファイルシステムプロトコルの同時処理管理技術に従って、例えばファイルに対する書き込み動作といったいくつかの種類の動作には、ロックが要求され得る。ファイルストアオブジェクトＦ１に対する書き込みまたは読み出し等、所定のファイルシステム動作要求（セッション識別子を含む）を受信すると、アクセスノードは、このようなロックが必要か否かを特定し得る（構成要素５８１６）。ロックが必要であり、かつアクセスノードに既にキャッシュされていない場合、対応内部バージョンの動作要求が、アクセスノードからメタデータノードへ送信され得る（構成要素５８１９）。メタデータノードは、競合するロックステートインジケータが既に存在するか（例えばＦ１は別のクライアントのために既にロックされているため）否かを特定し得る。このような競合ロックが見つかった場合（構成要素５８２０にて特定）、例えば対象オブジェクトは既にロックされていることを示すエラーメッセージを送信することで、クライアントのファイルシステム動作要求は拒否され得る（構成要素５８２１）。競合が見つからなかった場合、メタデータノードは、例えば対応ロックステートインジケータを含むＦ１のステート情報を格納するのに使用する論理ブロックのための永続性格納場所を特定し得る（構成要素５８２２）。例えば、いくつかの実施形態において、Ｆ１に関して保存するロックステートインジケータ及び／または他のステートメタデータに領域を割り当てるために、図５７ａまたは５７ｂにおいて例示される技術のうちの１つが使用され得る。ステート情報は永続性格納場所に格納され（構成要素５８２５）、そしてロックステートインジケータを含むステートメタデータの少なくとも一部がアクセスノードへ提供され得る。

要求された動作（例えばＦ１に対する読み出しまたは書き込み）は、例えばアクセスノードまたはメタデータノードによる格納サブシステムに対する内部Ｉ／Ｏ要求の結果完了し、そして対応応答がクライアントへ送信され得る。アクセスノードは、ロックステートインジケータを自身のセッションメタデータキャッシュに追加し、セッション中のクライアントからの後続要求に応答するために、例えば後続要求のうちの少なくともいくつかに関してメタデータサブシステムとのインタラクションを要求することなく、キャッシュされたロックステートインジケータ、キャッシュされたリース設定、及び／またはキャッシュされたセッション識別子を使用し得る（構成要素５８２８）。描かれた実施形態において、セッションが終了した時と場合、そのメタデータは、アクセスノードのキャッシュと、メタデータノードの要求で割り当てられた永続性格納場所との両方から削除され得る（構成要素５８３１）。いくつかのファイルシステムプロトコルに従って、セッション関連メタデータの少なくとも一部は、例えばファイル格納サービスを利用するアプリケーションが実行されるホストにてインスタンス化されたデーモン等、サービスのクライアント側コンポーネントにも提供及び／またはキャッシュされ得ることに留意されたい。

図５９は、少なくともいくつかの実施形態による、分散格納サービスにおいて実行され得るクライアントセッションリースの更新動作の態様を例示するフロー図である。前述のように、リースは、格納サービスからクライアントに対する、ファイル、ディレクトリ、または他のクライアントアクセス可能格納オブジェクトの集合のステート制御の時間制限付き授与を表し得る。構成要素５９０１に示されるように、クライアントセッションＣＳ１中に、クライアントＣｌ１から、自動リース更新に至る動作のカテゴリに属するファイルストア動作要求ＯＲ１が、格納サービスのアクセスノードにて受信され得る。例えば、ＮＦＳ等のセッション指向ファイルシステムの特定のファイルに対する読み出し、書き込み、オープン、またはクローズ要求が受信され得る。様々な実施形態において、異なるファイルシステムプロトコルが、それぞれのリース更新動作の集合を定義し得る。少なくともいくつかの実施形態において、図５９において例示される残りの動作も、明示的リース更新命令に応じて実行され得る。要求は、アクセスノードのセッションメタデータキャッシュにおけるメタデータレコードのインデックス値として利用可能であり得るクライアントのセッション識別子（例えばＮＦＳクライアントＩＤ）を含み得る。

アクセスノードは、例えばセッションメタデータキャッシュ内において、クライアントセッションのリース情報（例えばリースが失効するように設定された時間）を検索し得る（構成要素５９０４）。リースがある閾値時間間隔Ｔ内に失効する予定である場合（構成要素５９０７にて特定）、アクセスノードはメタデータノードに対し、ＣＳ１の即時リース更新要求を送信し得る（構成要素５９１３）。しかしながら、リースが閾値時間間隔Ｔの後に失効する予定である場合、ＣＳ１のリース更新要求は、メタデータノードへバッチで送信される保留リース更新要求のバッファ集合へ追加され得る。格納動作が実行されることを動作要求ＯＲ１が要求する場合（例えばアクセスノードに既にキャッシュされたデータまたはメタデータでは当該要求が満たされ得ない場合）、即時更新要求が送信されたか否かに関係なく、格納動作がアクセスノードにより要求され得る（構成要素５９１６）。ＣＳ１のリース更新要求がバッファされるシナリオにおいて、バッファされたリース更新要求のうちの１つまたは複数は、動作要求ＯＲ１とは非同期的に、メタデータノードへ送信され得る（構成要素５９１９）。

リース更新要求のバッファ技術が実行される少なくともいくつかの実施形態において、メタデータノードの要求で格納された永続性バージョンのセッションメタデータに設定される有効性タイムアウトとは異なる有効性タイムアウトが、アクセスノードにキャッシュされたバージョンのセッションメタデータ（例えばセッション識別子及びセッションのＬＳＩを含む）に対し、構成または設定され得る。例えば、一実施態様において、ファイルシステムプロトコル設定に従ってリースタイムアウトが９０秒に設定された場合、メタデータサブシステムにおける永続性セッションメタデータレコードには１２０秒の有効性タイムアウトが使用され、一方アクセスノードのキャッシュにおける対応レコードには３０秒の有効性タイムアウト（例えばメタデータサブシステムの有効性タイムアウトとプロトコルのリースタイムアウトとの差に少なくとも一部基づく）が設定され得る。このような異なるタイムアウトの組み合わせを使用することで、クライアントが自身のリースの有益性を早く失うことなく、アクセスノードにおける少なくともいくつかの種類の潜在的障害または遅延が調整され得る。例えば、前に紹介された例示的タイムアウト設定では、いずれの事例においてもアクセスノードはメタデータサブシステムから３０秒ごとに１度そのキャッシュしたリース情報をリフレッシュするように要求され、一方クライアントの実際のリースは９０秒間有効であるため、数秒のバッチ遅延（例えば代替ノードへのアクセスノードのファイルオーバーにより生じる３０秒未満の遅延）が、プロトコルリースセマンティックの任意の侵害を生じるとは通常予想されない。リース更新動作はかなり頻繁に起こることが見込まれ得るため、このような実施態様において、アクセスノードのより短い有効性タイムアウトがアクセスノードとメタデータサブシステム間の追加トラフィックを生じる確率は、極めて低く保持され得る。一般に読み出し‐変更‐書き込みシーケンスにおける条件付き書き込み、分散トランザクション、及び／または複製ステートマシンの使用等の前述の技術のうちの少なくともいくつかも、クライアントセッション関連メタデータを管理するのに同様に使用され得ることに留意されたい。例えば、一実施態様において、クライアントセッションリースが失効し、サービスの様々なノード間に分散された複数のセッション関連ロックステートインジケータが削除される必要がある場合、分散トランザクションが使用され得る。

試行回数を利用する接続分散
数千のノードを含むと見込まれ、かつ数万または数十万の同時クライアント要求を処理すると予想されるいくつかの分散格納システムにおいて、目的とするパフォーマンス及びリソース使用目標を達成するためには、クライアント作業負荷の負荷分散は不可欠であり得る。少なくともいくつかのプロバイダネットワーク環境において、負荷分散ノードの集合は、様々なサービスとサービスの利用を所望するクライアント間の仲介として確立され得る。いくつかの実施形態において、このような中間負荷分散層が、クライアントデバイスと分散格納サービスのアクセスサブシステムの間に確立され得る。クライアントのために確立された分散格納サービスへのネットワーク接続（ＮＦＳマウント接続等）は、通常かなり長く続き、結果として、ユーザセッションが通常短い環境（例えばいくつかの種類のウェブサーバ環境）の場合よりも、作業負荷分散の問題がより複雑になり得る。例えば特定のクライアントのための接続を確立するために前に行われ不成功に終わった試行の数を考慮する後述の接続分散技術を含む多数の異なる技術が、分散格納サービスのアクセスノードの作業負荷レベルを管理するのに使用され得る。いくつかの実施形態において、同様に後述されるように、特定の作業負荷条件の下、接続はアクセスノードにより自発的に終了され得る。

図６０は、少なくともいくつかの実施形態による、分散格納サービスのために負荷分散層が構成されたシステムを例示する。描かれた実施形態において、負荷分散層６０９０は、プロバイダネットワーク６００２のリソースを使用して実装されたノード６０７０Ａ、６０７０Ｂ、６０７０Ｃ等の複数の負荷分散ノード（ＬＢＮ）６０７０を含む。分散格納サブシステムのアクセスサブシステム６０１０は、アクセスノード（ＡＮ）６０１２Ａ、６０１２Ｂ、６０１２Ｃを含むＡＮピアグループ６０６０Ａと、ＡＮ６０１２Ｋ、６０１２Ｌ、６０１２Ｍを含むＡＮピアグループ６０６０Ｂ等、複数のアクセスノード（ＡＮ）ピアグループ６０６０を有する。さらに詳しく後述されるように、少なくともいくつかの実施形態において、ＡＮピアグループのメンバーは、接続再分散動作のために、お互い協働し合い得る。異なる実施形態において、ＡＮピアグループ６０６０のメンバーは、格納サービスの複数のアクセスサブシステムノードの中から、様々な基準の任意の組み合わせに基づいて選択され得る。例えば、アクセスサブシステムの可用性要件（例えば単一限局性電源異常または他のインフラストラクチャ機能停止が、ＡＮグループの全てのメンバーにおいて障害を生じないという要件）、レイテンシ要件（例えばグループの異なるメンバーが同一レベルのレイテンシに対応可能であるという要件）、パフォーマンス能力要件（ＡＮピアグループの集合的に処理可能な合計処理量が、ある所望最小処理量を超えるという要件）に基づいて、当該選択が行われ得る。いくつかの実施態様において、ＡＮピアグループは、単一ラックに搭載されたハードウェアサーバ上に全て実装された複数のアクセスノードを含み得る。別の実施態様において、ＡＮピアグループの境界は、ラックの教会と一致し得ない。その代わりに、共有ネットワークアドレスのプレフィックス、障害許容力、または処理されているファイルストアの種類／数等の他の要素が、ピアグループを定義するのに使用され得る。

少なくともいくつかの実施形態において、プロトコルのＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）族は、クライアント１８０と格納サービスとの間の通信に使用され得る。クライアント１８０は、格納サービスにアクセスするためのエンドポイントとして公開されているネットワークアドレス(例えば仮想ＩＰアドレス）を有するＬＢＮ６０７０に対し、接続確立要求を送信し得る。異なる実施形態において、様々な種類の物理または仮想ネットワーク６０２２が、クライアントにより使用され得る。一実施態様において、前述のように、一部または全てのクライアント（隔離仮想ネットワークの一部として構成された演算インスタンス等）は、プロバイダネットワーク内のホストにおいてインスタンス化され、従って内部ネットワークを使用して負荷分散ノードに接続し得る。少なくとも一実施形態において、負荷分散ノード及び格納サービスのクライアントは両方とも、同じホスト上で実行され得る（例えば個別の仮想マシンとして）。その場合、ホスト外ネットワーク接続は要求され得ない。別の実施形態において、インターネットの一部等、プロバイダネットワーク６００２の外部のネットワークの一部が使用され得る。いくつかの実施形態において、複数のＬＢＮは、格納サービスに対応付けられる単一ＩＰアドレスに対するトラフィックに応じるように構成され得る。一実施態様において、特定のＬＢＮ６０７０はまずクライアントの接続確立要求を仮に受諾し、それからＬＢＮ６０７０は、プロバイダネットワーク６００２のネットワーク機構６０２４（例えばＬ３ネットワーク）を介してアクセスノード６０１２へ対応内部接続を確立するように試み得る。少なくともいくつかの実施形態において、後述のように、所定のアクセスノード６０１２は、特定の作業負荷条件の下、ＬＢＮが出した内部接続要求を拒否し、そしてＬＢＮは結果的に内部接続の確立に協力的な別のアクセスノード６０１２を探すように試み得る。いくつかの実施形態において、アクセスノードがＬＢＮの要求の受諾または拒否に使用する特定の基準は、ＬＢＮが既に行い不成功に終わった試行の数に依存し得る。例えば、不成功の試行の数が大きくなるにつれ基準は緩和され得るため、接続確立の確率は、試行回数と共に増大し得る。

描かれた実施形態において、各ＡＮ６０１２は、ローカル負荷分散モジュール（ＬＬＢＭ）６０１７（例えばＬＬＢＭ６０１７Ａ、６０１７Ｂ、６０１７Ｃ、６０１７Ｋ、６０１７Ｌ、６０１７Ｍ）と、アクセスマネジャー（ＡＭ）６０１５（例えばＡＭ６０１５Ａ、６０１５Ｂ、６０１５Ｃ、６０１５Ｋ、６０１５Ｌ、６０１５Ｍ）の２つのサブコンポーネントを有する。接続要求が受諾された後、いくつかの実施形態において、ＬＬＢＭは、ネットワーク機構６０２４を通じて、クライアントのためにＬＢＮが送信するカプセル化されたＴＣＰパケットを受信する責任を担い得る。様々な実施態様において、ＬＢＮは別のプロトコル（例えばユーザデータグラムプロトコル（ＵＤＰ）またはプロバイダネットワークで内部使用されるあるプロプライエタリプロトコル）を使用して、またはＴＣＰ自体を使用して、クライアントのＴＣＰパケットをカプセル化し得る。例えば、クライアントのＴＣＰパケット（そのヘッダーを含む）は、ＬＢＮとＬＬＢＭ間の転送処理用のＬＢＮのＴＣＰパケット内に含まれ得る。ＬＬＢＭは、ローカルＡＭに対応付けられたＴＣＰ処理スタックへパケットを渡す前に、パケットを解凍またはカプセル除去し得る。いくつかの実施態様において、ＬＬＢＭは、ＴＣＰシーケンス番号等の１つまたは複数のクライアントパケットヘッダーのコンテンツを、ＴＣＰ処理スタックへ転送する前に変更し得る。少なくともいくつかの実施形態において、ＬＢＮとＬＬＢＭの組み合わせによるクライアントパケットの編集（例えばカプセル化／解凍、ヘッダー変更等）により、まるでパケットが、ＬＢＮ及びＬＬＢＭを介してではなく、クライアント１８０に対し直接確立されたＴＣＰ接続上で受信されたかのように、ＴＣＰ処理スタックには現れ得る。ＡＭ６０１５は、例えばメタデータのキャッシュ化、メタデータサブシステム１２０及び／または格納サブシステム１３０とのインタラクションの管理等を含む格納サービスフロントエンド論理を実行し得る。さらに、いくつかの実施形態において、ＡＭ６０１５は、追加接続の受諾に関する決定に使用可能なＣＰＵメトリクス、ネットワークメトリクス、メモリメトリクス等、ＡＮの様々なリソースのローカル作業負荷メトリクスの集合を収集し得る。一実施形態において、ピアグループ６０６０の異なるピアのＡＭは、さらに詳しく後述されるように、それぞれの作業負荷レベルに関して相互に問い合わせ得る。

少なくともいくつかの実施形態によれば、クライアント１８０に代わってＬＢＮ６０７０から、試行回数パラメータを含む接続要求が、アクセスノード６０１２において受信され得る。試行回数パラメータは、負荷分散コンポーネントが特定のクライアント１８０のために接続を確立しようとした回数を示し得る。一実施形態において、クライアントは、ファイルシステムをマウントする要求（例えばそれに加えてＮＦＳマウント命令）を送り、そしてＬＢＮは、マウント命令を受信したことに応じて、その接続要求を生成し得る。その結果確立された接続は「マウント接続」と称され、同一クライアントからのいくつかの後続要求に使用され得る。別の実施形態において、他の格納サービス命令または要求（すなわちマウント要求以外の要求）が同様にまたは代わりに、接続確立要求を引き起こし得る。接続要求を受信すると、ＡＮは、接続要求に関する受諾決定に使用する１つまたは複数の作業負荷閾値レベル（例えば複数のリソースに対するそれぞれの閾値レベルＴｈ１、Ｔｈ２、・・・）を特定し得る。いくつかの実施形態において、閾値レベルのうちの少なくとも１つは、試行回数パラメータに基づき得る。例えば、第１試行に関してＣＰＵ作業負荷閾値はＴｃであり、一方第２試行に関してＣＰＵ作業負荷レベルは（Ｔｃ＋デルタ）に設定され、第２試行で接続が受諾される可能性を高くしている。１つの例示的シナリオにおいて、ＣＰＵ作業負荷の閾値レベルＴｃが特定され、かつネットワーク作業負荷の閾値レベルＴｎが特定される場合、ＡＮのＣＰＵ作業負荷メトリクがＴｃ未満であり、かつネットワーク作業負荷メトリクがＴｎ未満であれば、接続は受諾され得る。別のシナリオにおいて、ＣＰＵ作業負荷メトリクまたはネットワーク作業負荷メトリクのどちらかが対応閾値未満であれば、接続は受諾され得る。後述のいくつかの実施形態において、閾値との比較に使用される作業負荷メトリクスは、例えば接続受諾決定に対する短期の作業負荷変動の影響を低減するために、ある時間間隔を通して計算され得る。

アクセスサブシステムノードのローカル作業負荷メトリクまたはメトリクスが対応作業負荷閾値レベル未満であるという判定に応じて、接続は受諾されたという開示が、要求ＬＢＮ６０７０に提供され得る。接続要求と受諾開示の両方が、ＬＢＮとＬＬＢＭ間の通信に使用されている特定のプロトコル（例えばＵＤＰ、ＴＣＰ、またはある他のプロトコル）に従ってフォーマットされ得る。ＬＢＮ６０７０は、いくつかの実施形態において、ＡＮにより接続が受諾されたことをクライアントに対し確認し得る。ＬＢＮに選択されたＡＮ６０１２が、接続を受諾できない場合（例えばローカル作業負荷メトリクスが特定された閾値を超える場合）、接続拒否メッセージがＬＢＮへ送信され得る。そしてＬＢＮは、その要求（増加した試行回数パラメータを有する）を別のＡＮへ送信し、当プロセスは、接続確立が成功するまで、または試行回数がある最大許容試行回数を超えるまで、図６１に例示され後述されるように繰り返され得る。

接続が無事に確立された後に、ＬＢＮ６０７０は格納サービス要求のクライアント生成パケット指示を受信すると、ＬＢＮは、アクセスサブシステムノードのＬＬＢＭへパケットを送信し得る（例えばカプセル化されたフォーマットで）。ＬＬＢＭは、ＬＢＮから受信したメッセージのコンテンツを操作し（例えば元のクライアント生成パケットを解凍し）、処理のために元のパケットをＡＭ６０１５へ渡し得る。格納要求に応じて実行される必要のある動作の性質により、ＡＭは、いくつかの事例において、メタデータサブシステム１２０、または格納サブシステム１３０、または両バックエンドサブシステムと連絡する必要があり得る。格納サービス要求の指示は、適切なサブシステム（複数可）へ送信され得る。クライアントのサービス要求が応答を要する場合、応答は、反対の方向へ、例えばバックエンドサブシステム（複数可）からＡＮへ、ＡＮからＬＢＮを介してクライアントへ、流れ得る。受信パケットがＬＢＮによりカプセル化され、ＬＬＢＭにより解凍される少なくともいくつかの実施形態において、ＬＬＢＭは同様に発信パケットをカプセル化し、そしてＬＢＮは当該パケットを、クライアント１８０へ渡す前に解凍し得る。

図６１は、少なくともいくつかの実施形態による、負荷分散ノードと、分散格納サービスの複数のアクセスサブシステムノードとの間の例示的インタラクションを示す。描かれた実施形態において、クライアントが格納サービスに対し接続要求及び他の格納サービス要求を送ることができるように、仮想ＩＰアドレス６１０５（例えば、プロバイダネットワークの仮想コンピューティングサービスの異なる演算インスタンスにおいて、異なるネットワークインターフェイスに動的に対応付け可能であり、かつ単一ネットワークインターフェイスに結び付けられていないＩＰアドレス）が公開され得る。１つまたは複数のＬＢＮ６０７０は、常時仮想ＩＰアドレスに対するトラフィックを受諾する責任を担い得る。少なくともいくつかの実施形態において、ＬＢＮ（及び／またはＡＮ）は、演算インスタンスを使用して実行され得る。例えば、所定のＬＢＮは、汎用ハードウェアサーバにおいて開始されたプロバイダネットワークの仮想コンピューティングサービスの演算インスタンスにて実行されるプロセスを含み得る。クライアントは、接続確立要求６１０８を、仮想ＩＰアドレス６１０８へ送り得る。

描かれた実施形態において、ＬＢＮ６０７０は、クライアントの要求を受信し、特定のＡＮ６０１２Ｂを、対応内部接続要求を送信するべき第１ＡＮとして選択し得る。ＡＮを選択するのに、多数の異なる技術が使用され得る。例えば、いくつかの実施形態においてランダム選択が使用され得る、他の実施形態においてラウンドロビン選択が使用され得る、等が挙げられる。いくつかの実施形態において、各ＬＢＮは、ＡＮの集合（可用性、レイテンシ、処理能力、または前述の他の基準に基づいて定義される１つまたは複数のＡＮピアグループ等）と提携し、そしてＬＢＮは、その提携ＡＮにおいて指定された順序で、その接続試行を繰り返し得る。いくつかの実施形態において、複数のＬＢＮ及び複数のＡＮは両方とも同じラックに配置され、ＬＢＮはまず自身のラック内からＡＮを選択し得る。描かれた実施形態において、ＬＢＮは選択したＡＮ６０１２ＢにおけるＬＬＢＭ６０１７Ｂに対し、例えば１に設定された試行回数パラメータを有する第１接続試行６１３２Ａを送り得る。（いくつかの実施態様においては、試行回数パラメータは、第１試行ではゼロに設定され得る。）異なる実施形態において、要求の受諾または拒否に関する決定は、対象ＡＮにおけるＡＭ６０１５により、または対象ＡＮにおけるＬＬＢＭにより、または対象ＡＮにおけるＬＬＢＭとＡＭの組み合わせにより、行われ得る。

連絡した第１ＡＮがＬＢＮに対し拒否６１２３４Ａを送信する場合（例えば対応閾値を超える１つまたは複数のローカル作業負荷メトリクス６１１５Ｂに少なくとも一部基づいて）、ＬＢＮは第２ＡＮ（描かれた実施例におけるＡＮ６０１２Ａ）を選択し得る。ＬＢＮ６０７０は、第２ＡＮにおけるＬＬＢＭ６０１７Ａに対し、増加した試行回数パラメータを有する第２接続要求試行６１３２Ｂを送り得る。拒否６１３４Ｂが再び受信された場合（例えばＡＮ６０１２Ａのローカル作業負荷メトリクス６１１５Ａに基づいて）、ＬＢＮ６０７０は第３ＡＮ６０１２Ｃを選択し、そのＬＬＢＭ６０１７Ｃへ第３試行６１３２Ｃを送り得る。描かれた例示的シナリオにおいて、第３ＡＮ６０１２Ｃは、そのローカル作業負荷メトリクス６１１５Ｃの分析に基づいて受諾６１３６を送り返し、そしてＡＭ６０１５Ｃとクライアント１８０との間に適宜接続が確立される。描かれた実施形態において、接続確立が成功した後、格納サービスとクライアント１８０との間のネットワークパケットは、経路６１５７に沿って流れる。例えば、クライアントはＬＢＮ６０７０へパケットを送信し、ＬＢＮはＬＬＢＭ６０１７Ｃへパケットを（カプセル化された、または変更された表現を潜在的に使用して）送信し、ＬＬＢＭのパケットマニピュレータ６１５５は受信したパケットを解凍または変更し、操作結果をＡＭ６０１５Ｃへ送り得る。そしてＡＭ６０１５Ｃは、メタデータサブシステム及び／または格納サブシステムとのインタラクションを伴い得る要求された格納動作を開始し得る。

図６２は、少なくともいくつかの実施形態による、行われた接続試行の回数により変わり得る接続受諾基準の例を示す。描かれた実施形態において、所定のリソース（ＣＰＵまたはネットワーク帯域等）に関するＡＮのネイティブすなわち基準処理能力６２０２は、接続受諾判定に使用する調整後処理能力（ＡＣ）６２０６となるように、障害オーバーヘッド要素６２０４により変更され得る。例えば、１つのシナリオにおいて、ＡＮのネイティブＣＰＵ処理能力が毎秒Ｘ動作である場合、その処理能力の５分の１（０．２Ｘ）は、様々な種類の障害時に起こり得る一時的な作業負荷増加を補償するために取って置かれ得る。従って、このようなシナリオにおいて、調整後のＣＰＵ処理能力は、毎秒０．８Ｘ動作（（Ｘ−０．２Ｘ）動作）に設定される。

ＡＮにおいて所定のリソースに関して収集されたローカル作業負荷メトリクスは、短期的変動だけでなく、長期的動向も示し得る。格納サービス動作のために確立された接続（ＮＦＳのために設定されたマウント接続等）は通常長く続くため、直近のメトリクスのみを基にして接続を受諾／拒否することは望ましくあり得ない。従って、直近のメトリク６２１２と、ある履歴メトリクスの集合６２１４（例えばそのリソースに関して、ここ最近１５分または１時間にわたり収集されたメトリクス）との組み合わせから、調整後の負荷メトリクス（ＡＬ）６２１６が取得され得る。いくつかの実施形態において、例えば経時的にメトリクスの重要度の低減を表現またはモデル化するために、調整後負荷を計算する時、減衰関数６２１５（例えば指数関数的減衰または線形減衰）が履歴メトリクスに適応され得る。

ＡＮにおいて特定の試行回数パラメータを有する接続要求を受諾するために、所定のリソースに関する調整後負荷６２１６は、試行回数に依存する閾値（そのリソースに関する調整後処理能力で表現される）と比較され得る。従って、接続受諾基準テーブル６２５５に示されるように、試行回数パラメータが１の接続要求は、検討中のリソースに対するＡＬが０．５^*ＡＣ以下である場合に受諾され得る。接続要求が１度失敗し、従って試行回数が２に設定された場合、ＡＬが０．５５^*ＡＣ以下である接続は受諾され得る。試行回数値が３の場合、受諾基準はさらに緩和されるため、ＡＬが０．６^*ＡＣ以下である場合に接続は受諾される。試行値が４の場合、ＡＬは０．７５^*ＡＣ以下である必要があり、そして試行値が５の場合、ＡＬは０．８５^*ＡＣ以下である必要があり得る。従って、描かれた実施形態において、より多い回数接続が拒否されると、最終的に受諾するＡＮはより高い負荷に対応することが可能になり得る。他の実施形態において、試行値Ｋを有する接続要求を受諾するために、受諾ノードの作業負荷レベルは、より少ない試行値（Ｋ−Ｌ）を有する接続要求を受諾するのに要する作業負荷レベルよりも低くある必要があり得る、反対の手法が使用され得る。例えば高い負荷条件の下では新規接続試行が阻止されるシナリオにおいては、試行値が増加する程に接続受諾の相対的緩和が低減するこのような手法が使用され得る。少なくともいくつかの実施形態において、閾値条件、並びにＡＣ及びＡＬの演算に使用されるパラメータ及び関数（例えば減衰関数）は、全て構成可能な設定であり得る。異なる実施形態において受諾基準を定義する別個の試行回数値の数は異なり、少なくとも一実施形態において試行回数値自体は構成可能なパラメータであり得る。いくつかの実施形態において、パラメータ、関数、及び／または閾値は、例えば達成された結果の分析に基づいて、時間と共に動的に変更され得る。少なくともいくつかの実施形態において、受諾基準のうちのいくつかは、試行回数値の範囲と同じであり得る。例えば試行値が１及び２である場合、これと同じ閾値が使用され得る。

いくつかの実施形態において、前述のように、接続受諾判定を行う時に、複数のリソースに対応付けられたローカル作業負荷レベルが考慮され得る。図６３は、少なくともいくつかの実施形態による、複数のリソースに対応付けられた作業負荷レベル、並びに接続確立試行回数に依存し得る接続受諾基準の例を示す。調整後負荷レベルと対応する調整後処理能力の５つの例が、配列６３１２において示される。ＡＬ［ＣＰＵ］はアクセスノードの調整後ＣＰＵ作業負荷を表し、同時にＡＣ［ＣＰＵ］は調整後ＣＰＵ処理能力を表す。ＡＬ［Ｎｅｔ］は調整後ネットワーク負荷を表し、そしてＡＣ［Ｎｅｔ］は調整後ネットワーク処理能力を表す。ＡＬ［Ｍｅｍ］は調整後メモリ負荷を表し、そしてＡＣ［Ｍｅｍ］は調整後メモリ処理能力を表す。ＡＬ［Ｄｓｋ］はアクセスノードの調整後ローカル格納デバイス処理能力負荷を表し、そしてＡＣ［Ｄｓｋ］は調整後格納デバイス処理能力を表す。少なくともいくつかの実施形態において、アクセスノードにおけるオペレーティングシステム構造により表されるオープンソケット等の論理リソースに関しても、調整後負荷及び処理能力が特定され得る。そのようなオペレーティングシステム構造に関する調整後作業負荷（ＡＬ［ＯＳＳ］）及び調整後処理能力（ＡＣ［ＯＳＳ］）は、少なくともいくつかの実施形態において、接続受諾判定において考慮され得る。リソースごとに、調整後負荷及び調整後能力は同じ単位で表現され得る。例えばネットワーク負荷がパケット／秒で表される場合、ネットワーク処理能力もパケット／秒で表され得る。

ＡＣ配列要素で表される閾値は、マルチリソース接続受諾基準テーブル６３５５に示されるように、様々な試行回数値ごとに決定され得る。描かれた実施形態において、異なる試行回数レベルに関して、異なるリソースの組み合わせが考慮され得る。例えば、試行回数が２の場合、ＣＰＵ、ネットワーク、及びメモリの閾値が対応する調整後負荷と比較され得るのに対し、試行回数がＫの場合、ＣＰＵ負荷と閾値のみが比較され得る。テーブル６３５５における「＆＆」記号はブール演算子「ＡＮＤ」を示すため、例えば試行回数４において接続を受諾するには、ＣＰＵとネットワークの両基準が満たされる必要があり得る。様々な実施形態において、異なるリソースに関して、負荷対閾値比較の異なるブール演算子の組み合わせが使用され得る。例えば、ＯＲ、またはＡＮＤ、またはＯＲかつＡＮＤが使用され得る。

図６４は、少なくともいくつかの実施形態による、分散格納サービスにおいて試行回数に基づき接続分散を実施するために実行され得る動作の態様を例示するフロー図である。構成要素６４０１に示されるように、クライアントがサービスに対して格納関連要求を送れるように、負荷分散ノードのネットワークアドレス（例えば図３において例示される種類の隔離仮想ネットワーク内からアクセス可能であり得る仮想ＩＰアドレス）の集合が、クライアントに公開され得る。クライアントからの接続要求が、特定のＬＢＮであるＬＢＮ１において受信され得る（構成要素６４０４）。今度はＬＢＮ１が、選択されたアクセスノードＡＮに対し、接続を確立しようと試みた回数を示す試行回数パラメータを含む対応接続要求を送り得る（構成要素６４０７）。接続確立試行を送る次のＡＮを選択するのに様々な手法が使用され得る。例えばラウンドロビン手法を使用して、またはＬＢＮ１からＡＮにおいてどれほど最近接続が確立されたか等のいくつかの他の要素に基づいて、ＡＮがランダムに選択され得る。

ＡＮは、１つまたは複数のリソースに関する調整後ローカル作業負荷メトリクス（ＷＭ）と、接続を受諾／拒否するために作業負荷メトリクスと比較する閾値（ＷＴ）とを特定し得る（構成要素６４１０）。閾値のうちの少なくともいくつかは、試行回数値によって異なり得る。いくつかの実施形態において、閾値は調整後リソース処理能力で表現され、一方調整後リソース処理能力は、ネイティブすなわち基準リソース処理能力及び障害調整要素から導き出され得る。いくつかの実施形態において、図６３に示されるように、リソース特定受諾条件の様々なブール演算子の組み合わせが使用され得る。構成要素６４１３にて特定されるように、受諾基準が満たされた場合、例えば試行回数値に対し検討中のリソースのＷＭが当該リソースのＷＴ以下である場合、ＬＢＮ１は接続が受諾されたと知らされ得る（構成要素６４２８）。接続が受諾された後、クライアントから格納要求を表すパケットがＬＢＮ１において受信され、そして当該パケットは、接続が確立されたＡＮにおけるＬＬＢＭ（ローカル負荷分散モジュール）へ送信され得る（構成要素６４３１）。いくつかの実施態様において、クライアントのパケットは、ＬＢＮ１によりカプセル化され、ＬＬＢＭにより解凍または抽出され得る（構成要素６４３４）。ＬＬＢＭは、クライアントの要求に応えるのにどの格納サービス動作が必要か決定するためにパケットコンテンツが分析されるＡＮにおけるネットワーク処理スタックへ、パケットを転送し得る。これらの動作に対する要求は、必要に応じてサービスの他のサブシステム（例えばメタデータサブシステム及び／または格納サブシステム）へ送信され得る（構成要素６４３７）。

ＬＢＮ１により選択されたＡＮにおいて接続を受諾する基準が満たされない場合（同様に構成要素６４１３において検出）、接続試行は拒否され得る（構成要素６４１７）。ＬＢＮ１が接続を確立するために、最大許容数の試行（「最大試行回数」）を既に行った場合（構成要素６４１９にて検出）、いくつかの実施形態において、接続確立が失敗したことを示すエラーメッセージがクライアントへ返され得る（構成要素６４２２）。多くの実施形態において、接続確立の失敗の可能性を非常に低く保つように、試行回数ベースの受諾基準は選択され得る。接続確立失敗の数は記録され、そして失敗の数または割合が目標レベルを超えないように保つために、必要に応じて追加ＡＮが構成され得る。

クライアントに関してＬＢＮ１がまだ最大許容数の接続試行を送っていない場合（同様に構成要素６４１９にて検出）、ＬＢＮ１は、接続要求を送るべき別のＡＮを選択し得る（構成要素６４２５）。増加した試行回数パラメータを有する新たな接続試行が選択されたＡＮへ送信され、そして構成要素６４０７以降に対応する動作が繰り返され得る。いくつかの実施形態において、ＬＢＮ１が最初のＡＮを選択するのに使用した技術のうち同じ種類のものが、後続の試行のためのＡＮを選択するのに使用され得る。別の実施形態において、ＬＢＮ１は、試行回数に基づいてＡＮを選択する自身の基準を変更し得る。例えば、最初のＡＮはランダムに選択され、一方次のＡＮは、様々なＡＮとの接続確立の前の試行においてどれだけＬＢＮ１が成功したかに基づいて、選択され得る。このような一実施形態において、ＬＢＮは、様々なＡＮとの自身の接続確立成功率の統計を保持し、当該統計を使用して、過去により頻繁に接続を受諾できていたＡＮを選択し得る。

ピアグループ作業負荷情報を使用する接続再分散
ＮＦＳマウント接続等のファイル格納システムに対し確立される接続は、多くの場合長い時間持続し得る。ある前の時間間隔における１つまたは複数のリソースのリソース作業負荷レベル等、接続要求が受信された時の接続受諾判定に関連する情報は、接続の持続時間中のある後の時点でのアクセスノードにおける実情を必ずしも示し得るとは限らない。一実施例において、アクセスノードは、自身の調整後ＣＰＵ負荷がＸであった時に接続を受諾し得たが、調整後ＣＰＵ負荷がある期間１．５Ｘに留まる後の時間においても尚も使用され得る。従って、いくつかの実施形態において、アクセスノードは、ある状況下では自身の作業負荷を再分散するように試み得る。

図６５は、少なくともいくつかの実施形態による、アクセスノードピアグループのメンバーの作業負荷インジケータに基づいて、クライアント接続の再分散を試み得る分散格納サービスのアクセスサブシステムの例を示す。ＡＮ６５１２Ａ、６５１２Ｂ、６５１２Ｃの３つのノードを含むアクセスノードピアグループが示される。ピアグループにおけるメンバー構成は、前述のように、異なる実施形態における様々な要素に基づいて決定され得る。様々な要素には、例えば可用性、レイテンシ、処理能力、コロケーション、または共有ネットワークアドレスプレフィックスが含まれる。描かれた実施形態において、各ピアグループメンバーは、ＣＰＵ、ネットワーク、メモリ、及びＡＮの他のリソースに関して前述された観測負荷等のローカル作業負荷メトリクス６１５５（例えば６１１５Ａ、６１１５Ｂ、または６１１５Ｃ）と、ピアグループの他のＡＮにおける作業負荷レベルのインジケータ６５０２との、少なくとも２つの種類の作業負荷メトリクスを収集し得る。描かれた例示的構成において、ＡＮ６５１２Ａは、ＡＮ６５１２Ｂ、６５１２Ｃからのピア作業負荷インジケータ６５０２Ａを収集し、ＡＮ６５１２Ｂは、ＡＮ６５１２Ａ、６５１２Ｃからのピア作業負荷インジケータ６５０２Ｂを収集し、そしてＡＮ６５１２Ｃは、ＡＮ６５１２Ａ、６５１２Ｂからのピア作業負荷インジケータを収集し得る。作業負荷インジケータが収集される方法、及び／または作業負荷インジケータの性質またはコンテンツは、異なる実施形態において異なり得る。いくつかの実施形態において、例えば、所定のＡＮは単純に、ある選択された時点に、自身のそれぞれのピアに対し接続確立クエリを送信し、ピアが接続を受諾する用意があるか否かを示す応答を受信し得る。前述のように接続受諾判定が試行回数パラメータに影響され得るいくつかの実施形態において、接続確立クエリは試行回数パラメータも含み得る（例えば「１」の試行回数パラメータ値が使用され得る）。クエリを送るＡＮは、ある時間間隔において、それぞれのピアがどれだけの数の接続を受諾する用意があったかを記録し得る。各ＡＮが接続受諾判定を行う際、自身のローカル作業負荷メトリクスを考慮することが見込まれる実施形態において、接続受諾率は、正確かつ取得が簡単な作業負荷インジケータとして役に立ち得る。別の実施形態において、ＡＮは単純に、定期的またはあるスケジュールに従って、それぞれのローカル作業負荷メトリクスの要約または概要を交換し、そしてこのような概要が作業負荷インジケータとして使用され得る。いくつかの実施形態において、作業負荷インジケータはクエリに応じてのみ送信され、一方で他の実施形態において、作業負荷インジケータは、クエリが受信されたか否かに関係なく、ピアグループメンバーに対しプッシュし得る。描かれた実施形態において、クエリ／応答６５７０に対応付けられた全トラフィック及び処理オーバーヘッドが閾値未満に保たれるように、作業負荷情報の共有に使用される特定の技術が選択（または変更）され得る。

ピアグループの各ＡＮは、ＡＮ６５１２Ａにおける接続Ｃ１１、Ｃ１２、・・・、Ｃ１ｎ、ＡＮ６５１２Ｂにおける接続Ｃ２１、Ｃ２２、・・・、Ｃ２p、ＡＮ６５１２Ｃにおける接続Ｃ３１、Ｃ３２、・・・、Ｃ３ｎ等の確立された接続すなわちオープン接続のある集合を有する。アクセスノードはそれぞれ、自身のオープン接続に関するそれぞれの接続統計６５０４を保持し得る。例えば、統計６５０４ＡはＡＮ６５１２Ａにおいて保持され、統計６５０４ＢはＡＮ６５１２Ｂにおいて保持され、そして統計６５０４ＣはＡＮ６５１２Ｃにおいて保持され得る。特定の接続Ｃｊｋに関して保持される接続統計６５０４は、例えば接続経過期間の測定（例えばＣｊｋが確立された時間）、接続上のトラフィックの量と時間の分散、接続上要求された格納動作（例えばファイルオープン、読み出し、書き込み等）の数、パケットのサイズ、中断されるパケットの数等を含み得る。作業負荷の再分散ために接続を閉じるまたは切断するとＡＮが決定する時と場合に、接続統計６５０４は分析され、そして統計に基づき得る閉止対象選択基準に従って、１つまたは複数の接続が閉じられ得る。使用されているネットワークプロトコルに応じて、ＡＮは、接続切断を開始するための適切なメッセージをクライアントへ送信し得る。いくつかの実施形態において、接続を手際よく閉じるためにメッセージの交換が必要となり得る。

いくつかの実施形態において、（ａ）アクセスノードにおける少なくとも１つのローカル作業負荷メトリク６１１５が再分散閾値を超える、（ｂ）収集された作業負荷インジケータから導き出されたピア処理能力可用性基準が満たされる、以上の条件が両方ともそろった場合に、接続を閉じる決定がアクセスノード６５１２において行われ得る。例えば、１つのシナリオにおいて、ＡＮ６５１２のピアの少なくとも７０％が最新の利用可能な作業負荷インジケータに基づいて新たな接続を受諾する用意があり、かつＡＮ６５１２の自身の作業負荷レベルが十分高いレベルに達した場合、ＡＮ６５１２は選択された接続を閉止または中断するように決定し得る。ローカル作業負荷ベースの基準が使用され得るため、ＡＮのローカルリソースが大量に利用されている時のみ、接続再分散は試行される（例えばあまりにも大量に利用されている場合は、どの新規接続も受諾され得ない）。ピア処理能力可用性基準が考慮され得るため、例えば、閉じられた接続の他端のクライアントは、接続を確立してその格納サービス要求ストリームを続けるのに妥当な機会を有し得る。

ある接続（または複数の接続）を閉じる決定がなされた場合、少なくともいくつかの実施形態において、前述のように接続統計６５０４の分析に基づいて、閉じる対象となる特定の接続（複数可）が選択され得る。例えば、同じクライアントの接続が異なるＡＮにおいて繰り返し閉じられる変動シナリオを避けるために、ある閾値時間よりも長く存在している接続が、閉止対象として積極的に選ばれ得る。いくつかの実施形態において、より大量のリソース使用をもたらしたトラフィックを有する接続（例えばリソース集中格納動作に使用されている接続）は、ＡＮにおいてより適度なリソース使用をもたらしている接続と比べて、優先閉止対象とみなされ得る。そしてＡＮは、使用されている特定のネットワークプロトコル（例えばＴＣＰ）に従って、選択された接続（複数可）の閉止を開始し得る。少なくともいくつかの実施形態において、接続閉止に応じて、クライアントは別の接続を確立しようと試み得る。そして負荷分散ノード（現在閉じられた接続の確立に参加したものと同じＬＢＮ、または別のＬＢＮであり得る）は、選択されたＡＮ（例えば接続を閉じたＡＮのピアグループに所属する）に対し、クライアントのための接続確立要求を出し得る。クライアントの接続を受諾する用意のあるＡＮが見つかるまで（または負荷分散ノードの接続試行回数が最大試行回数に達するまで）、前述のものと同様の接続確立プロトコルが使用され得る。接続再分散決定をするために使用されるピア処理能力可用性基準が、ＡＮの接続を受諾する用意を示す良きインジケータである場合、クライアントは閉じられた接続を置き換える新たな接続を確立することがすぐに可能となり得る。セッション指向ファイルシステムが対応される少なくともいくつかの実施形態において、図６８を参照して後述されるように、クライアントは、接続再分散の前に使用されていた同一セッションを継続することでさえも可能であり得る。一実施形態において、特定のＡＮが特定のクライアントＣ１との接続を閉じた後、再接続閾値時間間隔内に同一のクライアントＣ１のための後続接続要求をＡＮが受信した場合、例えば同一クライアントの接続が繰り返し閉じられるシナリオを避けるために、接続要求は拒否され得る。

一実施形態において、負荷分散ノードは、例えばクライアントの接続の閉止がＡＮにより開始されたことをクライアントに知らせる、または気付かれることなく、クライアントに対する置き換え接続を透過的に確立することが可能であり得る。負荷分散ノードは、再分散関連接続切断が開始されたことを検出することが可能であり得る（例えばＡＮから受信したパケットヘッダー及び／またはパケット本体のコンテンツを調べることにより）。再分散関連接続切断を発見した際、負荷分散ノードは、別のＡＮを選択し、クライアントに知らせるまたは通知することなく、当該の別のＡＮに対する別の接続の確立を開始し得る。負荷分散ノードがその要求を受諾するＡＮを見つけられたとしても、少なくともいくつかの実施形態において、クライアントの観点からすると何も変わっていないように見え得る（すなわちクライアントは再分散の影響を全く気付き得ない）。このような透過性を達成するために、いくつかの実施態様において、負荷分散装置及びアクセスサブシステムは、接続切断を開始したＡＮと置き換えＡＮ間の接続ステート情報転送を共同で管理する必要があり得る。

図６６は、少なくともいくつかの実施形態による、アクセスサブシステムノードにおいて使用され得る接続受諾及び再分散基準の例を示す。描かれた実施形態において、試行回数ベースの接続受諾閾値は、前述と同様の方法で使用され得る。しかしながら、少なくともいくつかの実施形態において、使用される接続再分散技術は、接続受諾基準と無関係であり得ることに留意されたい。例えば、前述の試行回数ベースの接続受諾技術が使用されなくても、接続再分散は実施形態において使用され得る。

図６６に描かれた実施形態において、前述の実施例のうちのいくつかのように、異なる試行回数レベルに使用される閾値により、試行回数値が大きくなるにつれ、接続は受諾されやすくなり得る。従って、例えば、試行回数３の接続要求を拒否するには、ＡＮの調整後ＣＰＵ負荷（ＡＬ［ＣＰＵ］）は調整後ＣＰＵ処理能力（ＡＣ［ＣＰＵ］）の０．６倍を超える必要があり、かつＡＮの調整後ネットワーク負荷（ＡＬ［ｎｅｔ］）は調整後ネットワーク処理能力（ＡＣ［ｎｅｔ］）の０．６倍を超える必要があり得る。しかしながら、試行回数値４の接続要求を拒否するには、ＣＰＵとネットワークの調整後負荷はそれぞれより高い（それぞれＡＣ［ＣＰＵ］の０．８倍と、ＡＣ［ｎｅｔ］の０．８倍）必要があり得る。

いくつかの要素の組み合わせは、図６６において例示される例示的再分散基準に寄与する。１番目に、ＣＰＵ、またはネットワーク、またはその両方の調整後ローカル負荷レベルが、対応する調整後処理能力の０．８５倍を超えなければならない。２番目に、調整後メモリ負荷が、調整後メモリ処理能力の０．８５倍を超えなければならない。３番目に、再分散のためアクセスノードにおいて前の接続が閉じられてから、少なくとも６００秒が経過しなければならない。そして４番目に、ピアアクセスノードが新規接続を受諾する用意がある推定確率（ピアグループメンバーから収集された作業負荷インジケータから取得され得る）が７０％を超える必要があり得る。従って、描かれた実施形態において、ＡＮにより接続が終了されるまでには、かなり厳しいテストの集合を通過する必要があり得る。

図６７は、少なくともいくつかの実施形態による、接続再分散を実施するために、分散格納サービスのアクセスサブシステムにおいて実行され得る動作の態様を例示するフロー図である。構成要素６７０１において示されるように、多数のネットワーク接続Ｃ１、Ｃ２、・・・、Ｃｎが、マルチテナント分散格納サブシステムのアクセスノードＡＮ１と、サービスの１つまたは複数のクライアントのための１つまたは複数の負荷分散ノード（ＬＢＮ）との間に確立され得る。前述のように、いくつかの実施形態において、ネットワークアドレスの集合（例えばプロバイダネットワークの隔離仮想ネットワーク内からアクセス可能なプライベート仮想ＩＰアドレス、またはインターネットからアクセス可能なパブリックアクセス可能ＩＰアドレス）が、負荷分散ノードに設定され、サービスへアクセスを所望するクライアントへ公開され得る。いくつかの実施形態において、接続Ｃ１‐Ｃｎを確立するのに試行回数ベースの接続受諾基準が使用されており、一方他の実施形態において、接続は試行回数を考慮せずに確立され得た。いくつかの実施形態において、ＡＮ１は、前述のようにＬＢＮにより送信されるパケットを傍受し操作するローカル負荷分散モジュール（ＬＬＢＭ）を備え、一方で他の実施形態において、ＡＮ１はこのようなＬＬＢＭを含み得ない。

ある時間枠Ｔの間に、ＡＮ１は、ＡＮのＣＰＵ（複数可）、ＡＮのネットワークモジュール等のリソースに関するローカル作業負荷情報と、多数のピアＡＮから取得されるピアグループ作業負荷インジケータとの、２種類の作業負荷情報を収集し得る（構成要素６７０４）。いくつかの実施形態において、ＡＮ１は、選択したピアの集合（例えば前述の種類の基準に基づいて選択されたピアグループのメンバー）に対し、作業負荷関連クエリを送り、そしてそれに応じて作業負荷インジケータが受信され得る。他の実施形態において、ピアグループのＡＮはお互いに、様々な時点にそれぞれの作業負荷インジケータを能動的にプッシュし合い得る。いくつかの実施態様において、ＡＮ１は、ピアＡＮ（例えばＡＮ−ｋ）に対し時々クエリを送り、ＡＮ−ｋが接続を受諾する用意があるかを特定し、そしてＡＮ−ｋの応答は、ＡＮ−ｋの作業負荷のインジケータとみなされ得る。少なくとも一実施態様において、ＡＮ１は、ＡＮ−ｋに対し接続確立要求を送り得る（例えば接続確立に関するクエリを送る代わりに）。いくつかの実施形態において、ＡＮは、ピアＡＮに対し定期的に自身の現在のローカル作業負荷推定の要約または概要を、オンデマンドでまたは能動的に提供し得る。一実施形態において、作業負荷インジケータは、例えば管理メッセージまたはハートビートメッセージといった、ＡＮ間で交換される他の種類のメッセージ上に載せられ得る。

描かれた実施形態において、終了または閉止する接続が選ばれるのに先立って、いくつかの基準が満たされる必要があり得る。ＡＮ１は、自身のローカル作業負荷メトリクスが、第１再分散閾値を超えるか否かを特定し得る（構成要素６７０７）。接続受諾のための調整後負荷（ＡＬ）計算に関して前述されたように、いくつかの実施形態において、ローカル作業負荷メトリクスは、経時的な素のメトリクスの変化を考慮した調整値を使用して表され得る。接続受諾基準を定義するのに使用される調整後処理能力（ＡＣ）に関しても前述されたように、いくつかの実施形態において、第１再分散閾値は、ネイティブリソース処理能力の一部を可能性のある障害を処理するためのオーバーヘッドとして取って置く、様々なリソースの調整後処理能力単位で表現され得る。別の実施形態において、接続受諾決定に考慮される作業負荷メトリクス及び／またはリソースの集合とは異なる作業負荷メトリクス及び／またはリソースの集合が、再分散決定において考慮され得る。

再分散のローカル作業負荷ベース基準が満たされた場合、ＡＮ１は、ピア処理能力可用性基準が満たされたか否かを特定し得る（構成要素６７１０）。描かれた実施形態において、ピア処理能力可用性基準は、他のＡＮから取得された作業負荷インジケータに基づいて決定され得る。少なくともいくつかの実施形態において、ピア可用性基準を満たすことは、ＡＮ１が特定のクライアントに対する接続を終了した場合、そのクライアントが別のＡＮと接続を確立できる確率がかなり高いことを示し得る。例えば、１つのシナリオにおいて、ＡＮ１の自身の調整後負荷（選択されたリソースのある集合に関する）が対応する調整後処理能力の９０％を超え、同時にＡＮ１がピア作業負荷インジケータを使用して、自身のピアグループのメンバーの少なくとも７５％が、対応する調整後処理能力の４０％未満の調整後負荷を有することを特定でき、従って新規接続を受諾する見込みがある場合に、ピア処理能力可用性基準は満たされ得る。少なくともいくつかの実施形態において、所定のピアＡＮ−ｋに関するＡＮ１において利用可能な直近の作業負荷インジケータは、ある前の時点のＡＮ−ｋのステートを表し、しかも異なる作業負荷インジケータは、異なる時点を表し得ることに留意されたい。そのため、このような実施形態において、ピア処理能力可用性決定は、精確なデータではなく、近似データに基づいて行われ得る。

再分散のローカル作業負荷基準とピア処理能力可用性基準が満たされた場合、描かれた実施形態において、ＡＮ１は、最近のＴｍｉｎ時間単位内に再分散目的で自身の接続のうちのいずれかが閉じられていたか否かも特定し得る（構成要素６７１３）。例えば、図６６に例示されるシナリオにおいて、Ｔｍｉｎは６００秒に設定された。前の再分散関連接続終了から最小閾値設定Ｔｍｉｎを超える時間が経過した場合（またはこれがＡＮ１における第１再分散試行である場合）、閉止目的選択ポリシーに基づいて、特定の接続Ｃｊが終了対象として選ばれ得る（構成要素６７１６）。対象選択ポリシーは、接続経過時間（いくつかの実施形態において変動的動作を避けるために、より最近確立された接続は選択される可能性が低くあり得る）、接続上のトラフィック量、接続に対応付けられた様々なＡＮリソース（例えばＣＰＵ、メモリ等）の使用量等、様々な要素を考慮し得る。いくつかの実施形態において、ＡＮ１は、閉止対象を選択するのに接続統計６５０４を利用し得る。

描かれた実施形態において、選択された対象接続の終了または閉止は、例えば使用されているネットワークプロトコルの適切な接続終了シンタックスに従って、ＡＮ１から開始され得る（構成要素６７１９）。Ｃｊが確立されていた対象のクライアントは、接続が中断／閉止されたことを特定すると、選択されたＬＢＮに対し、別の接続確立要求を送り得る（構成要素６７２２）。ＬＢＮは従って、クライアントのために、例えばＡＮ２といったある他のＡＮと接続を確立し得る（構成要素６７２５）。使用されている接続受諾基準とＡＮ１の作業負荷の変化により、この新規接続は、場合によってはＡＮ１自体に受諾され得ることに留意されたい。

図６７に描かれた実施形態において、ローカル作業負荷ベースの再分散閾値が満たされない場合（構成要素６７０７にて検出）、ＡＮ１は、構成要素６７０４に示されるように、後続の時間枠の間にローカルとピアの作業負荷情報を収集することで、自身の通常動作を続け得る。再分散の２つの条件のうちの１つが満たされない場合、例えばピア処理能力可用性基準が満たされない（構成要素６７１０）、または再分散を行うには最後に接続が終了されてから十分な時間が経過していない場合、ＡＮ１は、自身の過剰作業負荷に対応するために描かれた実施形態においていくつかの追加動作を行ない得る。例えば、構成要素６７２８に示されるように、ＡＮ１は、例えば選択されたパケットの処理を遅らせることで、またはパケットを中断することで、任意で自身のオープン接続のうちの１つまたは複数を抑圧し始め得る。当然、使用しているネットワークプロトコルの性質により、このような動作は、いくつかの事例においてクライアントからの再送信を引き起こし、終了する接続を選択できる十分な時間が少なくとも経過するまでは大して早急な助けにはなり得ない。別の実施形態において、構成要素６７０７のローカル作業負荷ベースの再分散閾値が満たされた場合、ＡＮ１は、たとえ他の２つの条件（構成要素６７１０と６７１３に該当）のうちの少なくとも１つが満たされなかったとしても、選択された接続を閉じ得る。いくつかの実施形態において、図６７における接続を閉じるか否かを決定するのに考慮される３つの条件は、示されたものとは別の順序で確認され得ることに留意されたい。例えば、いくつかの実施形態において、前の接続終了から経過した時間が最初に確認され得る、またはピア処理能力可用性が最初に確認され得る場合もあり得る。

いくつかの実施形態において、分散格納サービスにおいて対応されるファイルシステムプロトコルのうちの少なくとも１つは、前述のようなセッション指向であり得る。例えばセッション識別子が、クライアントのために生成され、リソースのリース及び／またはロックに対応付けられ得る。再分散のためのクライアント接続の終了は、このような実施形態において、積極的防止ステップが行われない限り、所望しないセッション終了を招き得る。図６８は、少なくともいくつかの実施形態による、接続再分散イベントを越えてクライアントセッションを保持するために、分散格納サービスにおいて実行され得る動作の態様を例示するフロー図である。例えば明示的セッション確立要求に応じて、またはクライアントＣｌ１が特定の種類の格納要求を出した時に、クライアントセッションＣＳ１がクライアントＣｌ１のために確立されると、特定のＡＮからセッション確立要求を受信するサービスのメタデータサブシステムノードにより、または当該メタデータサブシステムノードにおいて、対応するセッションメタデータが格納され得る。構成要素６８０１において示されるように、セッションメタデータは、ＣＳ１に使用されている特定のアクセスノード（例えばメタデータノードに対しセッション確立要求を送り、かつＣｌ１からの後続格納要求に使用される予定であるＡＮ）を特定するフィールドを含み得る。図５５にも例示されるように、このようなフィールドは、「責任アクセスノード」（ＲＡＮ）フィールドと称され得る。クライアントＣｌ１は、ＡＮ１を介して送られた自身の後続格納関連要求におけるセッションメタデータの一部として生成されたセッション識別子（例えばＮＦＳ「クライアントＩＤ」パラメータ）を特定し得る。

構成要素６８０４において示されるように、ＡＮ１はその後、例えば前述の種類の再分散基準を使用して、再分散のためにＣｌ１の接続を終了／閉止することを決定し得る。従って、セッションメタデータのＲＡＮフィールドは、「ヌル」に（またはどのＡＮも責任を担わないことを示すある他の値に）設定され得る（構成要素６８０７）。いくつかの実施形態において、メタデータへの変更は、ＡＮ１の要求で、メタデータノードにより実行され得る。接続は、ＡＮ１の主導で終了され得る。

最終的には、Ｃｌ１は、接続が閉じられたことを検知した後、格納サービスへの接続を再確立しようと試みるために、例えば負荷分散ノードに対し、別の要求を送り得る（構成要素６８１０）。接続を受諾するために、別のアクセスノード（ＡＮ２）が、ＬＢＮがＣｌ１の代わりに送った接続確立要求に応答し得る（構成要素６８１３）。クライアントＣｌ１は、接続の終了前に使用していたのと同一のセッション識別子を有する格納サービス要求（例えばオープン（）、読み出し（）、または書き込み（））を送り得る（構成要素６８１６）。ＡＮ２は、このような格納サービス要求を受信し、クライアント指定セッション識別子に対応するメタデータのステータスを特定するために、メタデータサブシステムに対しクエリを送信し得る（構成要素６８１９）。メタデータサブシステムが指定セッション識別子のセッションメタデータを見つけられた場合、かつそのメタデータのＲＡＮフィールドが「ヌル」に設定されている場合（構成要素６８２２にて検出）、これは、ＡＮ２が既存のメタデータを有するＣＬ１のセッションを続けることと、Ｃｌ１のセッションの責任を担うこととを受諾可能であることをＡＮ２に示し得る。従って、ＣＳ１のメタデータのＲＡＮフィールドは、ＡＮ２の識別子に設定され（構成要素６８２５）、そしてＣＳ１は再開され得る。そうではなく、ある理由でＣＳ１のメタデータレコードが見つからない場合、またはＣＳ１のメタデータ内のＲＡＮフィールドが「ヌル」に設定されていなかった場合、描かれた実施形態において、クライアントのために新規セッションが作成され得る（構成要素６８２８）。少なくともいくつかの実施形態において、新規セッションを確立することは、１つまたは複数のロック／リースの獲得を伴い、このような実施形態においては、ＡＮ２を責任アクセスノードとして現行のセッションが開始され得た場合よりも多いリソースを要し得る。

様々な実施形態において、図８ａ、８ｂ、９、１０、１５、２０、２１、２２、２３、２７、２８、３２、３８、４１、４２、４３、４４、５１、５２、５３、５８、５９、６４、６７、６８のフロー図において例示されるものとは異なる動作が、前述の分散ファイル格納サービス技術を実施するのに使用され得ることに留意されたい。示される動作のうちのいくつかは、いくつかの実施形態において実行され得ない、または別の順序で実行され得る、または順次ではなく同時に実行され得る。少なくともいくつかの実施形態において、前述の技術は、ファイルストア以外の種類の格納サービスにおける作業負荷変動を管理するのにも使用され得る。例えば、ボリュームレベルブロック格納インターフェイスを公開する格納デバイス、またはファイルシステムインターフェイスではなくウェブサービスインターフェイスを使用して任意の格納オブジェクトへアクセス可能にする非構造化格納デバイスのために、またはリレーショナルもしくは非リレーショナルデータベースのテーブルもしくはパーティションにアクセスするために、同様の技術が使用され得る。

１つまたは複数の業界標準ファイルシステムインターフェイスに対応する拡張縮小性、可用性、及び耐久性の高いファイル格納システムを実施する前述の技術は、多数のシナリオにおいて、及び様々な顧客のために、役立ち得る。プロバイダネットワークの多数の顧客が、利用可能な莫大な量のコンピューティングパワーを活用するために、自身のアプリケーションのうちのいくつかを既にクラウドへ移行している。しかしながら、単一ファイル内に非常に大量のデータ（例えばペタバイト）を格納し、そしてパフォーマンスに影響を与えることなく多数のクライアントが同時に当該ファイルにアクセスする能力に関して、このようなアプリケーションにはいくつかの制約が残り得る。ファイルシステムディレクトリ階層に関しても、例えば、所定のディレクトリが格納可能なオブジェクトの数、及びディレクトリ階層が含み得るレベルの数等、拡大縮小制約が残り得る。アクセスサブシステム、メタデータサブシステム、及び格納サブシステム等、様々なファイル格納サービスサブシステムにシームレスにノードを追加する能力は、このような拡張縮小制限を緩和するのに役立ち得る。データからメタデータの論理分離は、メタデータの要件（より厳しい要求を有し得る）をデータに対し課すことなく、メタデータとデータの両方に関して、パフォーマンス、可用性、及び耐久性の所望する別個のレベルを達成するのに役立ち得る。例えば、メタデータは優先的にＳＳＤに格納され、一方データはより安価な回転ディスクベースデバイスに収容され得る。プロバイダネットワーク環境における他の格納システムは、よく知られているファイルシステムインターフェイスと、多数のアプリケーションが依存するように設計されている種類の一貫性セマンティックとに、対応し得ない。

単一ページ書き込みの条件付き書き込み機構と、複数ページ書き込みの分散トランザクションスキームとを含む説明された楽観的同時性制御機構は、従来のロックベーススキームが多く使用される時に一般的に発生するボトルネックの種類のうちのいくつかを避けるのに役立ち得る。エクステント予約超過及び可変ストライプサイズ決定は、領域利用効率性とメタデータサイズの間のトレードオフを管理するのに使用され得る。オフセットベースの輻輳制御技術は、例えばアプリケーション起動時に所定の構成ファイルが多数の同時クライアントスレッドにより読み出される必要があり得るアプリケーション等、特定の種類のアプリケーションの全体Ｉ／Ｏパフォーマンスを改善するのに役立ち得る。オブジェクト名前変更技術は、大きな分散ファイルストアにおいて必然的に起こり得るメタデータノード障害発生時に、ファイルシステム一貫性を確保するのに役立ち得る。前述の名前空間管理技術は、数百万のオブジェクトを有するファイルシステムを実行し（単一ディレクトリ内であっても）、同時にオブジェクト数が増大しても比較的一律の応答時間を維持するのに使用され得る。クライアントセッション管理キャッシュ及びリース更新技術は、セッション関連オーバーヘッドを低く維持するのに役立ち得る。負荷分散及び再分散手法は、過重負荷起因障害の可能性を低減するのに役立ち得る。

本開示の実施形態は以下の条項を以って説明され得る。
１．１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記コンピューティングデバイスは、
分散マルチテナントファイル格納サービスのアクセスサブシステムにおいて、特定のクライアント代わりにファイルストア動作のためにクライアントセッションを確立する要求を受信し、
前記アクセスシステムから前記ファイル格納サービスのメタデータサブシステムに、前記クライアントセッションと対応付けられるセッション識別子の要求を送信し、
前記メタデータサブシステムから前記アクセスサブシステムに、前記クライアントセッションのメタデータの１つまたは複数の構成要素が格納される永続性セッション格納場所に少なくとも基づいてセッション識別子を提供し、前記１つまたは複数の構成要素が前記クライアントセッションに対応付けられたリースの表示を含み、
前記アクセスサブシステムにおいて、前記特定のクライアントへの前記セッション識別子の送信の前に、前記セッション識別子及び前記リースの表示をキャッシュし、
前記メタデータサブシステムにおいて、特定のファイルストアオブジェクトに対応付けられたロックステートインジケータを格納する永続性ロック格納場所を特定し、前記ロックステートインジケータが前記クライアントからの異なる要求に応じて生成され、前記異なる要求が前記セッション識別子を含み、前記ロックステートインジケータが前記セッション識別子を含み、
前記アクセスサブシステムにおいて、前記ロックステートインジケータをキャッシュし、
前記アクセスサブシステムにおいて、前記クライアントから前記特定のファイルストアオブジェクトに対するサービス要求に応えるために、前記キャッシュされたセッション識別子、前記リースの前記キャッシュされた表示、及び前記キャッシュされたロックステートインジケータを活用し、
前記リースに対応付けられたタイムアウトが経過したという判定に応じて、（ａ）前記永続性ロック格納場所から前記ロックステートインジケータ、及び（ｂ）前記永続性セッション格納場所から前記セッション識別子を削除する、
ように構成される、前記システム。

２．前記１つまたは複数のコンピューティングデバイスが、
前記アクセスサブシステムにおいて、前記クライアントセッション中に前記特定のクライアントから受信された異なるサービス要求がリース更新動作のカテゴリに属すると決定し、
前記リースの更新を開始する、
ようにさらに構成される、条項１に記載のシステム。

３．前記リースの前記更新を開始するために、前記１つまたは複数のコンピューティングデバイスが、
前記異なるサービス要求に応じて、前記アクセスサブシステムにおいて、前記リースが、閾値期間よりも長い期間の後に失効する予定であると決定し、
前記メタデータサブシステムへの単一バッチリース更新要求の中に、それぞれのクライアントセッションに対応付けられたそれぞれのリースを更新する複数の要求を結合する、
ようにさらに構成される、条項２に記載のシステム。

４．前記アクセスサブシステムが、前記クライアントセッションを確立する前記要求が受信される特定のアクセスノードを含む複数のアクセスノードを備え、前記１つまたは複数のコンピューティングデバイスが、
前記永続性セッション格納場所に格納された前記１つまたは複数の構成要素のうちの特定の構成要素の中に、前記特定のアクセスノードの識別子を格納する、
ようにさらに構成される、条項１に記載のシステム。

５．前記セッションステート識別子及び前記ロックステートインジケータが、（ａ）ＮＦＳ（ネットワークファイルシステム）のバージョンまたは（ｂ）ＳＭＢ（サーバメッセージブロック）のバージョンのうちの１つに従ってフォーマットされる、条項１に記載のシステム。

６．１つまたは複数のコンピューティングデバイスにより、
分散ファイル格納サービスのアクセスサブシステムから前記ファイル格納サービスのメタデータサブシステムに、特定のクライアントのクライアントセッションに対応付けられるセッション識別子の要求を送信することと、
前記アクセスサブシステムにおいて前記メタデータサブシステムから、前記クライアントセッションのメタデータの１つまたは複数の構成要素が格納される永続性セッション格納場所に少なくとも部分的に基づいてセッション識別子を受信することと、
前記特定のクライアントへの前記セッション識別子の送信の前に前記アクセスサブシステムにおいて前記セッション識別子をキャッシュすることと、
前記アクセスサブシステムにおいて、特定のファイルストアオブジェクトでロックが確保される前記クライアントから特定の要求を受信することであって、前記特定の要求が前記セッション識別子を含む、受信することと、
前記メタデータサブシステムにおいて、前記特定のファイルストアオブジェクトに対応付けられた競合するロックステートインジケータが異なるクライアントの代わりに作成されたと決定することと、
前記特定の要求を拒否することと、
を実行することを含む方法。

７．前記１つまたは複数のコンピューティングデバイスにより、
前記アクセスサブシステムにおいて、異なるファイル格納オブジェクトで別のロックが確保される、前記クライアントからの第２の要求を受信し、前記他の要求が前記セッション識別子を備えることと、
前記メタデータサブシステムにおいて、前記異なるファイルストアオブジェクトに対応付けられたロックステートインジケータを格納する永続性ロック格納場所を特定することであって、前記ロックステートインジケータが前記セッション識別子を備える、特定することと、
前記アクセスサブシステムにおいて、前記ロックステートインジケータをキャッシュすることと、
前記アクセスサブシステムにおいて、前記クライアントからの別の要求に応えるために、前記キャッシュされたセッション識別子及び前記ロックステートインジケータの前記キャッシュされた表示を活用することと、
を実行することをさらに含む、条項６に記載の方法。

８．メタデータの前記１つまたは複数の構成要素が、前記クライアントセッションに対応付けられたリースの表示を備え、前記１つまたは複数のコンピューティングデバイスにより、
前記アクセスサブシステムにおいて、前記リースの前記表示をキャッシュすること、
を実行することをさらに含む、条項７に記載の方法。

９．前記１つまたは複数のコンピューティングデバイスにより、
前記アクセスサブシステムにおいて、前記他の要求が、前記ファイルストアオブジェクトに対応付けられたリース更新動作のカテゴリに属すると決定することと、
前記リースの更新を開始することと、
を実行することをさらに含む、条項７に記載の方法。

１０．前記リースの前記更新を前記開始することが、
前記他の要求に応じて、前記アクセスサブシステムにおいて、前記リースが、閾値期間よりも長い期間の後に失効する予定であると決定することと、
前記メタデータサブシステムへの単一バッチリース更新要求の中に、それぞれのクライアントセッションに対応付けられたそれぞれのリースを更新する複数の要求を結合することと、
を含む、条項９に記載の方法。

１１．前記リースの前記更新を前記開始することが、
前記他の要求に応じて実行される動作の一部として前記アクセスサブシステムにおいて、前記リースが閾値期間よりも短い期間の後に失効する予定であると決定することと、
前記メタデータサブシステムに非バッチリース更新要求を送信することと、
を含む、条項９に記載の方法。

１２．前記１つまたは複数のコンピューティングデバイスにより、
前記アクセスサブシステムキャッシュにおいて前記セッション識別子の第１の有効性失効タイムアウト設定値を設定することと、
前記メタデータサブシステムにおいて前記セッション識別子の第２の有効性失効タイムアウトを設定することであって、前記第１の有効性失効タイムアウトが前記第２の有効性失効タイムアウトよりも小さい、設定することと、
を実行することをさらに含む、条項７に記載の方法。

１３．前記クライアントセッションのために使用されるファイルシステムプロトコルに従って、特定のリースタイムアウトが前記クライアントセッションに対応付けられ、前記第２の有効性失効タイムアウトが前記特定のリースタイムアウトよりも大きく、前記第１の有効性失効タイムアウトが、前記第２の有効性失効タイムアウトと前記特定のリースタイムアウトの差に少なくとも部分的に基づく、条項１２に記載の方法。

１４．前記アクセスサブシステムが、特定のアクセスノードを含む複数のアクセスノードを備え、前記１つまたは複数のコンピューティングデバイスにより、
前記メタデータサブシステムにセッション識別子の前記要求を前記送信する前に前記特定のアクセスノードにおいて、前記特定のクライアントから前記クライアントセッションを確立する要求を受信することと、
前記永続性セッション格納場所に格納されたメタデータの１つまたは複数の構成要素のうちの特定の構成要素の中に、前記特定のアクセスノードの識別子を格納することと、
を実行することをさらに含む、条項７に記載の方法。

１５．前記１つまたは複数のコンピューティングデバイスにより、
作業負荷分散解析に基づいて前記特定のアクセスノードにおいて、前記クライアントセッションを確立する前記要求のために使用されるネットワーク接続が閉じられると決定することと、
メタデータの前記特定要素から、前記特定のアクセスノードの前記識別子を削除することと、
を実行することをさらに含む、条項１４に記載の方法。

１６．前記異なるファイルストアオブジェクトが第１のファイルストアに属し、前記１つまたは複数のコンピューティングデバイスにより、
前記第１のファイルストアのために、前記ファイルストアの複数のオブジェクトのためのロックステートインジケータが格納される永続性格納オブジェクトを指定することであって、前記メタデータサブシステムにおいて前記永続性ロック格納場所を前記特定することが、前記ロックステートインジケータを格納する前記永続性格納オブジェクトの特定の部分を識別することを含む、指定することと、
を実行することをさらに含む、条項７に記載の方法。

１７．前記セッションステート識別子及び前記ロックステートインジケータが、（ａ）ＮＦＳ（ネットワークファイルシステム）のバージョンまたは（ｂ）ＳＭＢ（サーバメッセージブロック）のバージョンのうちの１つに従ってフォーマットされる、条項６に記載の方法。

１８．プログラム命令を格納する非一時的コンピュータアクセス可能格納媒体であって、前記プログラム命令は、１つまたは複数のプロセッサ上で実行されると、
分散ファイル格納サービスのアクセスサブシステムから前記ファイル格納サービスのメタデータサブシステムへ、特定のクライアントのクライアントセッションに対応付けられるセッション識別子の要求を送信し、
前記アクセスサブシステムにおいて、前記クライアントセッションのメタデータの１つまたは複数の構成要素が格納される永続性セッション格納場所に少なくとも部分的に基づいて、前記メタデータサブシステムからセッション識別子を受信し、
前記特定のクライアントへの前記セッション識別子の送信の前に前記アクセスサブシステムにおいて前記セッション識別子をキャッシュし、
前記アクセスサブシステムにおいて、前記メタデータサブシステムからファイルストアオブジェクトのロックステートインジケータを受信し、前記ロックステートインジケータが、前記クライアントセッション中に前記クライアントからの特定の要求に応じて前記メタデータサブシステムで生成され、
前記アクセスサブシステムにおいて、前記ロックステートインジケータをキャッシュし、
前記アクセスサブシステムにおいて、前記キャッシュされたセッション識別子及び前記ロックステートインジケータの前記キャッシュされた表示に少なくとも部分的に基づいて前記特定のファイルストアオブジェクトに対する前記クライアントからの別の要求に対する応答を決定する、
前記非一時的コンピュータアクセス可能格納媒体。

１９．メタデータの前記１つまたは複数の構成要素が前記クライアントセッションに対応付けられたリースの表示を備え、前記命令が、前記１つまたは複数のプロセッサで実行されると、
前記アクセスサブシステムにおいて、前記リースの前記表示をキャッシュする、
条項１８に記載の非一時的コンピュータアクセス可能格納媒体。

２０．前記命令が、前記１つまたは複数のプロセッサで実行されると、
前記アクセスサブシステムにおいて、前記他の要求が、前記ファイルストアオブジェクトに対応付けられたリース更新動作のカテゴリに属すると決定し、
前記アクセスサブシステムから前記リースの更新を開始する、
条項１９に記載の非一時的コンピュータアクセス可能格納媒体。

２１．前記リースの前記更新を開始するために、前記命令が、前記１つまたは複数のプロセッサで実行されると、
前記アクセスサブシステムにおいて前記他の要求に応じて、前記リースが、閾値期間よりも長い期間の後に失効する予定であると決定し、
前記メタデータサブシステムへの単一バッチリース更新要求の中に、それぞれのクライアントセッションに対応付けられたそれぞれのリースを更新する複数の要求を結合する、
条項２０に記載の非一時的コンピュータアクセス可能格納媒体。

２２．前記セッションステート識別子及び前記ロックステートインジケータが、（ａ）ＮＦＳ（ネットワークファイルシステム）のバージョンまたは（ｂ）ＳＭＢ（サーバメッセージブロック）のバージョンのうちの１つに従ってフォーマットされる、条項１９に記載の非一時的コンピュータアクセス可能格納媒体。

例示的コンピュータシステム
少なくともいくつかの実施形態において、分散ファイル格納サービスのアクセス、メタデータ、及び格納サブシステムのコンポーネント及び／または負荷分散ノードを実行する技術を含む、本明細書において説明される技術のうちの１つまたは複数の一部または全てを実施するサーバは、１つまたは複数のコンピュータアクセス可能媒体を含む、またはそのような媒体にアクセスするように構成される汎用コンピュータシステムを含み得る。図６９は、このような汎用コンピューティングデバイス９０００を例示する。例示される実施形態において、コンピューティングデバイス９０００は、入出力（Ｉ／Ｏ）インターフェイス９０３０を介してシステムメモリ９０２０（不揮発性及び揮発性メモリモジュールの両方を備え得る）に接続された１つまたは複数のプロセッサ９０１０を含む。コンピューティングデバイス９０００はさらに、Ｉ／Ｏインターフェイス９０３０に接続されたネットワークインターフェイス９０４０を含む。

様々な実施形態において、コンピューティングデバイス９０００は、１つのプロセッサ９０１０を含むユニプロセッサシステム、またはいくつか（例えば２つ、４つ、８つもしくは別の好適な個数）のプロセッサ９０１０を含むマルチプロセッサシステムであり得る。プロセッサ９０１０は、命令を実行可能な任意の好適なプロセッサであり得る。例えば、様々な実施形態において、プロセッサ９０１０は、様々な命令集合アーキテクチャ（ＩＳＡ）、例えばｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、ＭＩＰＳ‐ＩＳＡ、またはその他の好適なＩＳＡ等、そのうちのいずれかを実施する汎用または組込みプロセッサであり得る。マルチプロセッサシステムにおいて、それぞれのプロセッサ９０１０は一般に、必ずではないが、同一のＩＳＡを実施し得る。いくつかの実施態様において、従来のプロセッサの代わりに、または従来のプロセッサに加えて、グラフィック処理ユニット（ＧＰＵ）が使用され得る。

システムメモリ９０２０は、命令と、プロセッサ９０１０（複数可）によりアクセス可能なデータとを格納するように構成され得る。少なくともいくつかの実施形態において、システムメモリ９０２０は、揮発性及び不揮発性部分両方を備え得る。別の実施形態においては、揮発性メモリのみが使用され得る。様々な実施形態において、システムメモリ９０２０の揮発性部分は、静的ランダムアクセスメモリ（ＳＲＡＭ）、同期式動的ＲＡＭ、またはその他の種類のメモリ等、任意の好適なメモリ技術を使用して実行され得る。システムメモリの不揮発性部分（例えば１つまたは複数のＮＶＤＩＭＭを備え得る）に関して、いくつかの実施形態において、ＮＡＮＤフラッシュデバイスを含むフラッシュベースメモリデバイスが使用され得る。少なくともいくつかの実施形態において、システムメモリの不揮発性部分は、超コンデンサまたは他の蓄電装置（例えば電池）等の電源を含み得る。様々な実施形態において、メモリスタベースの抵抗ランダムアクセスメモリ（ＲｅＲＡＭ）、３次元ＮＡＮＤ技術、強誘電性ＲＡＭ、磁気抵抗ＲＡＭ（ＭＲＡＭ）、または様々な種類の相変化メモリ（ＰＣＭ）のうちのいずれかが、少なくともシステムメモリの不揮発性部分に使用され得る。例示される実施形態において、前述の方法、技術、及びデータ等、１つまたは複数の所望する機能を実行するプログラム命令及びデータは、システムメモリ９０２０内にコード９０２５及びデータ９０２６として格納されることが示される。

一実施形態において、Ｉ／Ｏインターフェイス９０３０は、プロセッサ９０１０と、システムメモリ９０２０と、データオブジェクトパーティションの物理レプリカを格納するのに使用される様々な種類の永続性及び／または揮発性格納デバイス等のネットワークインターフェイス９０４０または他の周辺インターフェイスを含む任意の周辺デバイスとの間のＩ／Ｏトラフィックをデバイス内で調整するように構成され得る。いくつかの実施形態において、Ｉ／Ｏインターフェイス９０３０は、１つのコンポーネント（例えばシステムメモリ９０２０）からのデータ信号を、別のコンポーネント（例えばプロセッサ９０１０）が使用するのに好適な形式に変換するために必要な任意のプロトコル変換、タイミング変換、または他のデータ変換を行い得る。いくつかの実施形態において、Ｉ／Ｏインターフェイス９０３０は、例えば周辺構成要素相互接続（ＰＣＩ）バス規格または汎用シリアルバス（ＵＳＢ）規格の変形等、様々な種類の周辺バスを介して取り付けられるデバイスのサポートを含み得る。いくつかの実施形態において、Ｉ／Ｏインターフェイス９０３０の機能は、例えばノースブリッジとサウスブリッジといった２つ以上の別々のコンポーネントに分割され得る。また、いくつかの実施形態において、システムメモリ９０２０に対するインターフェイス等、Ｉ／Ｏインターフェイス９０３０の機能性のうちの一部または全ては、プロセッサ９０１０に直接取込まれ得る。

ネットワークインターフェイス９０４０は、コンピューティングデバイス９０００と、例えば図１から図６８までにおいて例示される他のコンピュータシステムまたはデバイス等、ネットワーク９０５０（複数可）に接続された他のデバイス９０６０との間でデータ交換が可能なように構成され得る。様々な実施形態において、ネットワークインターフェイス９０４０は、例えばイーサネット（登録商標）ネットワークの類等、任意の好適な有線または無線汎用データネットワークを介して、通信に対応し得る。さらに、ネットワークインターフェイス９０４０は、アナログ音声ネットワークもしくはデジタルファイバ通信ネットワーク等の電気通信／電話ネットワークを介した、またはファイバチャネルＳＡＮ等の格納エリアネットワークを介した、またはその他の好適な種類のネットワーク及び／またはプロトコルを介した、通信に対応し得る。

いくつかの実施形態において、システムメモリ９０２０は、対応方法及び装置の実施形態を実行するために、図１から図６８に関して前述されたプログラム命令及びデータを格納するように構成されたコンピュータアクセス可能媒体の一実施形態であり得る。しかしながら、別の実施形態において、プログラム命令及び／またはデータは、異なる種類のコンピュータアクセス可能媒体上で受信、送信、格納され得る。一般に、コンピュータアクセス可能媒体には、例えばＩ／Ｏインターフェイス９０３０を介してコンピューティングデバイス９０００に接続されるディスクまたはＤＶＤ／ＣＤといった磁気媒体または光学式媒体等の非一時的記憶媒体またはメモリ媒体が含まれ得る。非一時的コンピュータアクセス可能記憶媒体には、コンピューティングデバイス９０００のいくつかの実施形態にシステムメモリ９０２０または別の種類のメモリとして含まれ得るＲＡＭ（例えばＳＤＲＡＭ、ＤＤＲ‐ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の任意の揮発性または不揮発性媒体も含まれ得る。さらに、コンピュータアクセス可能媒体には、送信媒体すなわち信号が含まれ、このような信号にはネットワーク及び／または無線リンク等の通信媒体を介して伝達される電気、電磁、またはデジタル信号等があり、当該信号伝達はネットワークインターフェイス９０４０を介して実行され得る。様々な実施形態において説明される機能性を実行するために、図６９に例示されるような多重コンピューティングデバイスの一部または全てが使用され得る。例えば、様々な異なるデバイス及びサーバ上で稼働するソフトウェアコンポーネントは、協働して機能性を提供し得る。いくつかの実施形態において、説明される機能性の一部は、汎用コンピュータシステムを使用して実行されるのに加えて、またはそれに代わって、格納デバイス、ネットワークデバイス、または特殊目的コンピュータシステムを使用して実行され得る。本明細書で使用される「コンピューティングデバイス」という用語は、少なくとも全てのこれらの種類のデバイスを指し、かつこれらの種類のデバイスに限定されない。

結論
様々な実施形態はさらに、コンピュータアクセス可能媒体に関する前述の説明に従って実行される命令及び／またはデータの受信、送信、または格納処理を含み得る。一般に、コンピュータアクセス可能媒体には、磁気媒体または光学式媒体等の記憶媒体もしくはメモリ媒体が含まれ得る。これには例えば、ディスクもしくはＤＶＤ／ＣＤ‐ＲＯＭ、ＲＡＭ（例えばＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭ等）、ＲＯＭ等の揮発性または不揮発性媒体、並びに送信媒体、すなわちネットワーク及び／または無線リンク等の通信媒体を介して伝達される電気、電磁、またはデジタル信号等の信号がある。

本明細書において図示及び説明される様々な方法は、方法の例示的実施形態を表す。方法は、ソフトウェア、ハードウェア、またはこれらの組合せで実行され得る。方法の順序は変更され、そして様々な要素が追加、並替、結合、省略、修正等され得る。

本開示の恩恵を受ける当業者には明らかであるように、様々な修正及び変更を行うことが可能である。全てのこのような修正及び変更を包含することが意図され、従って前述の説明も制限的な意味ではなく例示的な意味としてみなされるものとする。

Claims

１つまたは複数のコンピューティングデバイスを備えるシステムであって、前記コンピューティングデバイスは、
分散マルチテナントファイル格納サービスのアクセスサブシステムにおいて、特定のクライアントの代わりにファイルストア動作のためのクライアントセッションを確立する要求を受信し、
前記アクセスシステムから前記ファイル格納サービスのメタデータサブシステムに、前記クライアントセッションと対応付けられるセッション識別子の要求を送信し、
前記メタデータサブシステムから前記アクセスサブシステムに、前記クライアントセッションのメタデータの１つまたは複数の構成要素が格納される永続性セッション格納場所の少なくとも一部に基づいてセッション識別子を提供し、前記１つまたは複数の構成要素が前記クライアントセッションに対応付けられたリースの表示を含み、
前記アクセスサブシステムにおいて、前記特定のクライアントへの前記セッション識別子の送信の前に、前記セッション識別子及び前記リースの表示をキャッシュし、
前記メタデータサブシステムにおいて、特定のファイルストアオブジェクトに対応付けられたロックステートインジケータを格納する永続性ロック格納場所を決定し、前記ロックステートインジケータが前記クライアントからの異なる要求に応じて生成され、前記異なる要求が前記セッション識別子を含み、前記ロックステートインジケータが前記セッション識別子を含み、
前記アクセスサブシステムにおいて、前記ロックステートインジケータをキャッシュし、
前記アクセスサブシステムにおいて、前記クライアントから前記特定のファイルストアオブジェクトに対するサービス要求に応えるために、前記キャッシュされたセッション識別子、前記リースの前記キャッシュされた表示、及び前記キャッシュされたロックステートインジケータを活用し、
前記リースに対応付けられたタイムアウトが経過したという判定に応じて、（ａ）前記永続性ロック格納場所から前記ロックステートインジケータ、及び（ｂ）前記永続性セッション格納場所から前記セッション識別子を削除する、
ように構成される、システム。
前記１つまたは複数のコンピューティングデバイスが、
前記アクセスサブシステムにおいて、前記クライアントセッション中に前記特定のクライアントから受信された異なるサービス要求がリース更新動作のカテゴリに属すると決定し、
前記リース更新動作を開始する、
ようにさらに構成される、請求項１に記載のシステム。
前記リース更新動作を開始するために、前記１つまたは複数のコンピューティングデバイスが、
前記異なるサービス要求に応じて、前記アクセスサブシステムにおいて、前記リースが、閾値期間よりも長い期間の後に失効する予定であると決定し、
前記メタデータサブシステムへの単一バッチリース更新要求の中に、それぞれのクライアントセッションに対応付けられたそれぞれのリースを更新する複数の要求を結合する、
ようにさらに構成される、請求項２に記載のシステム。
前記アクセスサブシステムが、前記クライアントセッションを確立する前記要求が受信される特定のアクセスノードを含む複数のアクセスノードを備え、前記１つまたは複数のコンピューティングデバイスが、
前記永続性セッション格納場所に格納された前記１つまたは複数の構成要素のうちの特定の構成要素の中に、前記特定のアクセスノードの識別子を格納する、
ようにさらに構成される、請求項１に記載のシステム。
１つまたは複数のコンピューティングデバイスにより、
分散ファイル格納サービスのアクセスサブシステムから前記ファイル格納サービスのメタデータサブシステムに、特定のクライアントのクライアントセッションに対応付けられるセッション識別子の要求を送信することと、
前記アクセスサブシステムにおいて前記メタデータサブシステムから、前記クライアントセッションのメタデータの１つまたは複数の構成要素が格納される永続性セッション格納場所の少なくとも一部に基づいてセッション識別子を受信することと、
前記特定のクライアントへの前記セッション識別子の送信の前に前記アクセスサブシステムにおいて前記セッション識別子をキャッシュすることと、
前記アクセスサブシステムにおいて、特定のファイルストアオブジェクトでロックが確保される前記特定のクライアントから前記セッション識別子を含む特定の要求を受信することと、
前記メタデータサブシステムにおいて、前記特定のファイルストアオブジェクトに対応付けられた競合するロックステートインジケータが異なるクライアントの代わりに作成されたと決定することと、
前記特定の要求を拒否することと、
を実行することを含む方法。
前記１つまたは複数のコンピューティングデバイスにより、
前記アクセスサブシステムにおいて、異なるファイルストアオブジェクトで別のロックが確保される、前記特定のクライアントからの前記セッション識別子を備える第２の要求を受信することと、
前記メタデータサブシステムにおいて、前記異なるファイルストアオブジェクトに対応付けられた前記セッション識別子を備えるロックステートインジケータを格納する永続性ロック格納場所を特定することと、
前記アクセスサブシステムにおいて、前記ロックステートインジケータをキャッシュすることと、
前記アクセスサブシステムにおいて、前記特定のクライアントからの別の要求に応えるために、前記キャッシュされたセッション識別子及び前記ロックステートインジケータの前記キャッシュされた表示を活用することと、
を実行することをさらに含む、請求項５に記載の方法。
前記１つまたは複数のコンピューティングデバイスにより、
前記アクセスサブシステムにおいて、前記別の要求が、前記ファイルストアオブジェクトに対応付けられたリース更新動作のカテゴリに属すると決定することと、
前記リース更新動作を開始することと、
を実行することをさらに含む、請求項６に記載の方法。
前記リース更新動作を開始することが、
前記別の要求に応じて、前記アクセスサブシステムにおいて、前記リースが、閾値期間よりも長い期間の後に失効する予定であると決定することと、
前記メタデータサブシステムへの単一バッチリース更新要求の中に、それぞれのクライアントセッションに対応付けられたそれぞれのリースを更新する複数の要求を結合することと、
を含む、請求項７に記載の方法。
前記リース更新動作を開始することが、
前記アクセスサブシステムにおいて前記別の要求に応じて実行される動作の一部として、前記リースが閾値期間よりも短い期間の後に失効する予定であると決定することと、
前記メタデータサブシステムに非バッチリース更新要求を送信することと、
を含む、請求項７に記載の方法。
前記１つまたは複数のコンピューティングデバイスにより、
前記アクセスサブシステムキャッシュにおいて前記セッション識別子の第１の有効性失効タイムアウト設定値を設定することと、
前記メタデータサブシステムにおいて前記セッション識別子の第２の有効性失効タイムアウトを設定することであって、前記第１の有効性失効タイムアウトが前記第２の有効性失効タイムアウトよりも小さくなるように設定することと、
を実行することをさらに含む、請求項５に記載の方法。
前記アクセスサブシステムが、特定のアクセスノードを含む複数のアクセスノードを備え、前記１つまたは複数のコンピューティングデバイスにより、
前記メタデータサブシステムに前記セッション識別子の要求を送信する前に前記特定のアクセスノードにおいて、前記特定のクライアントから前記クライアントセッションを確立する要求を受信することと、
前記永続性セッション格納場所に格納されたメタデータの１つまたは複数の構成要素のうちの特定の構成要素の中に、前記特定のアクセスノードの識別子を格納することと、
を実行することをさらに含む、請求項５に記載の方法。
プログラム命令を格納する非一時的コンピュータアクセス可能格納媒体であって、前記プログラム命令は、１つまたは複数のプロセッサ上で実行されると、
分散ファイル格納サービスのアクセスサブシステムから前記ファイル格納サービスのメタデータサブシステムへ、特定のクライアントのクライアントセッションに対応付けられるセッション識別子の要求を送信し、
前記アクセスサブシステムにおいて、前記クライアントセッションのメタデータの１つまたは複数の構成要素が格納される永続性セッション格納場所の少なくとも一部に基づいて、前記メタデータサブシステムからセッション識別子を受信し、
前記特定のクライアントへの前記セッション識別子の送信の前に前記アクセスサブシステムにおいて前記セッション識別子をキャッシュし、
前記アクセスサブシステムにおいて、前記メタデータサブシステムから前記クライアントセッション中に前記特定のクライアントからの特定の要求に応じて前記メタデータサブシステムで生成されたファイルストアオブジェクトのロックステートインジケータを受信し、
前記アクセスサブシステムにおいて、前記ロックステートインジケータをキャッシュし、
前記アクセスサブシステムにおいて、前記キャッシュされたセッション識別子及び前記ロックステートインジケータの前記キャッシュされた表示の少なくとも一部に基づいて前記ファイルストアオブジェクトに対する前記特定のクライアントからの別の要求に対する応答を決定する、
非一時的コンピュータアクセス可能格納媒体。
メタデータの前記１つまたは複数の構成要素が前記クライアントセッションに対応付けられたリースの表示を備え、前記プログラム命令が、前記１つまたは複数のプロセッサで実行されると、
前記アクセスサブシステムにおいて、前記リースの前記表示をキャッシュする、
請求項１２に記載の非一時的コンピュータアクセス可能格納媒体。
前記プログラム命令が、前記１つまたは複数のプロセッサで実行されると、
前記アクセスサブシステムにおいて、前記別の要求が、前記ファイルストアオブジェクトに対応付けられたリース更新動作のカテゴリに属すると決定し、
前記アクセスサブシステムから前記リース更新動作を開始する、
請求項１２に記載の非一時的コンピュータアクセス可能格納媒体。
前記リース更新動作を開始するために、前記プログラム命令が、前記１つまたは複数のプロセッサで実行されると、
前記アクセスサブシステムにおいて前記別の要求に応じて、前記リースが、閾値期間よりも長い期間の後に失効する予定であると決定し、
前記メタデータサブシステムへの単一バッチリース更新要求の中に、それぞれのクライアントセッションに対応付けられたそれぞれのリースを更新する複数の要求を結合する、
請求項１４に記載の非一時的コンピュータアクセス可能格納媒体。