JP2015534175A - ソフトウェア定義ネットワークアタッチ可能記憶システムおよび方法 - Google Patents

Abstract

ソフトウェア定義ネットワークアタッチ可能記憶システムを確立する方法は、名前空間サーバおよびデータ空間サーバとして論理コンピュータシステムの第１および第２のセットを確立することをそれぞれ含む。各名前空間サーバは、ファイルおよびディレクトリ名と、ファイルおよびディレクトリ名に関連するユーザデータが常駐する場所の情報とを含むファイルシステムメタデータをそのメモリに記憶し、ファイルシステムメタデータの動的に更新されたコピーをその記憶システムに記憶し、少なくとも１つの要求クライアントコンピュータからの名前空間の所定のサブセットに対する記憶システムパス名要求を処理し、各要求に応答して要求クライアントコンピュータによる使用のためのハンドルを返送するように構成され、各データ空間サーバは、名前空間サーバによって決定されるハンドルに基づいてユーザデータをその記憶システムに記憶し取り出すように構成される。

Description

（関連出願の引用）
本願は、発明の名称が本願と同一の米国仮特許出願第６１／７０１，４４１号（２０１２年９月１４日出願）の利益を主張する。さらに、本願は、発明の名称が本願と同一の米国特許出願第１３／７５９，７９９号（２０１３年２月５日出願）の利益を主張する。これらの関連出願は、参照により本明細書に引用される。

（技術分野）
本発明は、ネットワークアタッチ可能記憶システムに関し、より具体的には、ソフトウェア定義される記憶システムに関する。

広範な文献が、ネットワークアタッチ可能記憶システムについて存在する。

本発明の実施形態は、記憶要求を取り扱うことにおいて、従来技術のファイルシステムと比べて劇的に増加した効率を実証する。本発明の実施形態が、名前空間サーバのメモリに記憶されたメタデータのみに基づいて、データ空間サーバによってアクセスされるファイルオブジェクトのためのハンドルを決定するために、名前空間サーバを使用するため、そのような実施形態は、これらのハンドルを決定するために、ディスクからのいかなる読み取り動作も行う必要がない。削減した数のディスク動作は、ファイルシステムの性能を向上させる。実際、ファイルシステムの実装は、典型的には、従来のファイルシステムより桁違いに良好である、記憶要求を取り扱うことの性能向上を実証する。

本発明の第１の実施形態では、複数の論理コンピュータシステム内でソフトウェア定義ネットワークアタッチ可能記憶システムを確立する方法が提供される。各コンピュータシステムは、メモリと、プロセッサと、記憶システムとを有する。本方法は、名前空間内で動作する名前空間サーバとして、論理コンピュータシステムの第１のセット、およびデータ空間サーバとして、論理コンピュータシステムの第２のセットを確立する、論理コンピュータシステム内でプログラムのセットを実行することを含む。論理コンピュータシステムの第１のセットは、少なくとも２つの論理コンピュータシステムを含む。各論理コンピュータシステムは、名前空間の異なるパーティション内で自律的に動作するように構成される。論理コンピュータシステムのうちのいくつかは、仮想コンピュータシステムであり得る。

本実施形態では、各名前空間サーバは、ファイルシステムメタデータであって、ファイルおよびディレクトリ名と、ファイルおよびディレクトリ名に関連付けられているユーザデータが常駐する場所についての情報とを含む、メタデータを、そのメモリに持続的に記憶し、ファイルシステムメタデータの動的に更新されたコピーをその記憶システムに記憶するように構成される。各名前空間サーバはさらに、そのメモリに持続的に記憶されるメタデータに基づいて、少なくとも１つの要求クライアントコンピュータからの名前空間の所定のサブセットに対する記憶システムパス名要求を処理し、各要求に応答して、要求クライアントコンピュータによる使用のためのハンドルを返送するように構成される。集合的に、名前空間サーバの全ては、名前空間の全体に対する記憶システムパス名要求を処理する。各データ空間サーバは、名前空間サーバによって決定され、少なくとも１つの要求クライアントコンピュータから受信されるハンドルに直接基づいて、ユーザデータをその記憶システムに記憶し、取り出すように構成される。

本発明の別の実施形態では、複数の論理コンピュータシステム内でソフトウェア定義ネットワークアタッチ可能記憶システムを確立する方法が提供される。各コンピュータシステムは、メモリと、プロセッサと、記憶システムとを有する。本方法は、名前空間サーバとして論理コンピュータシステムの第１のセット、およびデータ空間サーバとして論理コンピュータシステムの第２のセットを確立する、論理コンピュータシステム内で、プログラムのセットを実行することを含む。論理コンピュータシステムのうちのいくつかは、仮想コンピュータシステムであり得る。

本実施形態では、各名前空間サーバは、ファイルシステムメタデータであって、ファイルおよびディレクトリ名と、ファイルおよびディレクトリ名に関連付けられているユーザデータが常駐する場所についての情報とを含む、メタデータを、そのメモリに記憶し、ファイルシステムメタデータの動的に更新されたコピーをその記憶システムに記憶するように構成される。各名前空間サーバはさらに、少なくとも１つの要求クライアントコンピュータからの名前空間の所定のサブセットに対する記憶システムパス名要求を処理し、各要求に応答して、要求クライアントコンピュータによる使用のためのハンドルを返送するように構成される。各データ空間サーバは、名前空間サーバによって決定されるハンドルに基づいて、ユーザデータをその記憶システムに記憶し、取り出すように構成される。

関連実施形態では、名前空間サーバの少なくとも１つの厳密なサブセットは、名前空間の共有サブセットに対して記憶システムパス名要求を処理するために、クラスタとして動作するように構成され、名前空間の共有サブセットに対するファイルシステムメタデータは、クラスタ内の各名前空間サーバのメモリの中に常駐している。随意に、クラスタ内の名前空間サーバの数は、予測負荷条件下で、所望のレベルの速度、冗長性、および可用性を達成するように選択される。

別の関連実施形態では、データ空間サーバの少なくとも１つの厳密なサブセットは、データ空間の共有サブセットに対して、名前空間サーバによって決定されるハンドルに基づいて、ユーザデータをその記憶システムに記憶し、取り出すために、クラスタとして動作するように構成される。随意に、クラスタ内のデータ空間サーバの数は、予測負荷条件下で、所望のレベルの速度、冗長性、および可用性を達成するように選択される。

関連実施形態では、論理コンピュータシステムのうちの少なくともいくつかは、仮想コンピュータシステムである。さらなる関連実施形態では、論理コンピュータシステムの全ては、仮想コンピュータシステムである。

また、関連実施形態では、論理コンピュータシステムの第１および第２のセットは、互いに素である。代替として、論理コンピュータシステムの第１および第２のセットは、互いに素ではない。

別の関連実施形態では、ファイルシステムメタデータは、パス名の共有プレフィックスがコンパクトに記憶されるように、パトリシア木データ構造に従って構造化される。随意に、ファイルシステムメタデータは、（ｉ）パトリシア木を符号化するノードテーブル、および（ｉｉ）ファイルおよびディレクトリの属性を符号化するファイルテーブル、および（ｉｉｉ）ノードテーブルで使用される最大長より大きい長さを有する、文字列の名前を符号化する文字列テーブルに記憶される。さらなるオプションとして、ノードテーブル、ファイルテーブル、および文字列テーブルの各々は、持続性のために異なるファイルに動的に記憶される。さらなるオプションとして、ノードテーブル、ファイルテーブル、または文字列テーブルのうちの任意のものに対する任意の変更は、インテントログに記憶され、インテントログは、そのようなテーブルに対応するファイルを更新するために動的に使用される。単一の動作に関連する変更のうちの任意のものは、一緒に結び付けられ得る。さらに、ノードテーブル、ファイルテーブル、および文字列テーブルの各々は、固定サイズのエントリを有する異なるアレイであり得る。

別の関連実施形態では、クラスタによって管理されている名前空間データの共有サブセットに対する更新を取り扱う経過中に、そこへの各連続更新は、連続番号を与えられ、クラスタの論理コンピュータシステムは、連続番号に基づいて、事前定義された更新順を依然として保持しながら、非同期的に動作するように構成される。

実施形態の前述の特徴は、添付図面を参照して解釈される、以下の発明を実施するための形態を参照することにより、より容易に理解されるであろう。
図１は、本発明の実施形態による、Ｈｙｐｅｒｆｉｌｅｒのブロック図である。 図２は、いくつかのサブディレクトリを含む、パス名を伴うファイルにアクセスするための従来技術のネットワークアタッチド記憶（ＮＡＳ）システムに特有である、ディスクおよびネットワーク入出力動作を図示する、略図である。 図３は、図２と同一のパス名を伴うファイルにアクセスするために本発明の実施形態によるＨｙｐｅｒｆｉｌｅｒによって要求される、ディスクおよびネットワーク入出力動作を図示する、略図である。 図４は、パス名「ｘ／ｙ／ｚ０１２３４５６７８」を伴うファイルを作成するための本発明の実施形態によるＨｙｐｅｒｆｉｌｅｒにおける動作を図示する、略図である。

定義。本説明および添付図面で使用されるように、以下の用語は、文脈が別様に要求しない限り、指示される意味を有するものとする。

「アクティブディレクトリ」は、それ自体の名前がハッシュ化される、ハイパーサーバ上に常駐するディレクトリのバージョンであり、ファイルおよびサブディレクトリを作成し、削除し、一覧化し、およびアクセスするために使用されるディレクトリである。Ｈｙｐｅｒｆｉｌｅｒでは、各ディレクトリは、２つのバージョン、すなわち、前述のようなアクティブディレクトリ、およびパッシブディレクトリを有し得る。パッシブディレクトリは、ハッシュ化されたその親ディレクトリを有し、その親のリスト化およびトラバーサルにおいて適正に報告されるように存在している。時として、アクティブディレクトリおよびパッシブディレクトリは、同一のハイパーサーバにハッシュ値を持ち、したがって、単一のディレクトリに畳み込まれ得る。

「バッキングストア」は、ノードテーブル、文字列テーブル、およびファイルテーブルのコンテンツを複製する３つのファイルの集合である。

ハイパーサーバの「基数」は、ハイパーサーバで構成されるハイパーサーバメンバーの総数を決定付ける数である。Ｈｙｐｅｒｆｉｌｅｒにおける各ハイパーサーバは、実装することを選択する冗長性のレベルに応じて、１〜４の範囲内の異なる基数を有することができる。

Ｈｙｐｅｒｆｉｌｅｒ「クライアント」は、Ｈｙｐｅｒｆｉｌｅｒのファイルシステム名前空間におけるディレクトリのマウントを行う、任意のコンピュータである。Ｈｙｐｅｒｆｉｌｅｒクライアントは、利用可能な種々のサービスの要求を発行する遠隔手続呼び出し（ＲＰＣ）を介して、記憶サービスに遠隔でアクセスするために、ＦＵＳＥクライアントコンポーネントを実行する。マウント動作は、クライアントがＨｙｐｅｒｆｉｌｅｒと相互作用するために必要とする全てのデータ構造をロードし、Ｈｙｐｅｒｆｉｌｅｒは、それらが変化するとこれらのデータ構造を更新するであろう。「クライアントコンピュータ」という用語は、それ自体がクライアントとして役割を果たしているサーバを含む。

「データ空間」は、ユーザファイルデータが記憶される記憶リソースを管理する、Ｈｙｐｅｒｆｉｌｅｒの一部である。データ空間全体は、Ｈｙｐｅｒｆｉｌｅｒにおける全てのデータ可能ハイパーサーバを通して区分化され、その各々は、特定レベルの基数を提供するように構成される。これは、最高基数を伴うハイパーボリュームを管理するハイパーサーバ内に重要データを記憶することを可能にする一方で、本質的に一過性であるデータは、記憶コストを最適化するように、１に設定された基数を伴うハイパーボリューム上に記憶されることができる。ファイルおよびシンボリックリンクは、論理的に連続した範囲の集約として記憶される。

「ディレクトリハッシュテーブル（ＤＨＴ）」は、全てのパス名ベースの動作を行う際に使用されるテーブルである。全てのＨｙｐｅｒｆｉｌｅｒメンバーおよびクライアントに知られているハッシュ関数は、ＤＨＴ内のスロットへの目的とするファイルシステムオブジェクトの親ディレクトリの名前の多数対１のマッピングを行う。標的スロットは、そのオブジェクトに動作を行うために使用されるハイパーサーバのＨＩＤを含む。効果的に、このテーブルは、Ｈｙｐｅｒｆｉｌｅｒにおける全てのハイパーサーバにわたって、大域的な名前空間全体が区分化されることを可能にする。ＤＨＴは、単調に増加している世代番号によって保護される。１つのＤＨＴスロットのコンテンツが変更されるか、またはＤＨＴのサイズが変更される度に、世代番号が増加させられる。パス名ベースの遠隔手続呼び出しは、常に、標的ハイパーサーバがクライアントによって使用される任意の状態ＤＨＴを検出して更新することができるように、ＤＨＴ世代番号を搬送する。

「範囲」は、ユーザデータを記憶する、ハイパーボリュームの論理的に連続した部分である。Ｈｙｐｅｒｆｉｌｅｒにおける任意の範囲は、大域的に一意的な範囲ＩＤ（ＥＩＤ）を介して識別される。範囲は、最大４メガバイトに及ぶことができる。これは、長さが４メガバイト以下であるファイルにアクセスすることが、単一のディスク入出力動作のみを必要とすることを示唆する。

「範囲ＩＤ（ＥＩＤ）」は、Ｈｙｐｅｒｆｉｌｅｒの全体を通して任意の範囲を一意的に識別する、８バイト数である。ＥＩＤは、ハイパーボリュームが管理するデータリポジトリ内でその範囲が配置される場所についての情報、およびその範囲の長さとともに、それを所有するハイパーボリューム／ハイパーサーバのＨＩＤを組み込む。具体的には、ＥＩＤは、以下のフィールドを含み、その含んでいるハイパーボリュームからの不透明スカラーとして取り扱われる。（ｉ）範囲が割り付けられたハイパーボリュームのＨＩＤ。これは、Ｈｙｐｅｒｆｉｌｅｒ全体内で範囲を大域的に一意的かつアドレス可能にする。（ｉｉ）含んでいるハイパーボリューム内の範囲の開始ブロックの論理ブロックオフセット。これは、ハイパーボリューム内の開始ブロックの論理ブロックインデックスを直接識別する。（ｉｉｉ）範囲が及ぶ論理ブロックの総数。これは、範囲内で読み取るためにどれだけのメモリがキャッシュ内で利用可能にされなければならないかを、キャッシュマネージャに知らせる。

「ファイルテーブル（ＦＴ）」は、（ＳＴおよびＮＴとともに）３つの連続したアレイのうちの１つであり、それによって、ローカル名前空間が各ハイパーサーバ上で実装される。このアレイは、各ファイルの第１の範囲に対する範囲ＩＤとともに、ファイルまたはディレクトリの属性を記憶する。範囲ＩＤがＨｙｐｅｒｆｉｌｅｒ全体にわたって大域的であるため、データは、その名前空間コンポーネントが常駐する同一のハイパーサーバ内に常駐する必要はない。

本明細書で使用される場合、「Ｈｙｐｅｒｆｉｌｅｒ」という用語は、本明細書の出願人であるＰｅａｘｙ，Ｉｎｃ．によって開発されたソフトウェアを指し、Ｈｙｐｅｒｆｉｌｅｒは、従来のコンピュータハードウェア環境で作動し、単一の名前空間内のファイル記憶のためのスケーラブル設備を提供するように動的に拡張されることが可能な分散型ファイルシステムのコンポーネントとして、１つ以上の高可用性ミニクラスタ（本明細書では「ハイパーサーバ」と呼ばれる）を確立する。より一般的には、ＨＹＰＥＲＦＩＬＥＲは、広範囲のハードウェア環境でスケーラブル高性能ファイルサーバを実装するソフトウェアに対する、本明細書の出願人であるＰｅａｘｙ，Ｉｎｃ．の商標であるが、本明細書で使用される場合、「Ｈｙｐｅｒｆｉｌｅｒ」という用語は、前の文に記載される具体的な意味を有する。

「ハイパーサーバ」は、Ｈｙｐｅｒｆｉｌｅｒにおける名前空間またはデータ空間あるいは両方の一部分に対して、協調的に処理するように構成される論理コンピュータのクラスタである。（これに関する種々の実施形態では、論理コンピュータは、仮想マシンとして実装される。）したがって、Ｈｙｐｅｒｆｉｌｅｒ抽象的概念は、名前空間および／またはデータ空間の一部分に対して全て一斉に動作する、事前定義された数の仮想マシンをハイパーサーバとして一緒にグループ化する。ハイパーサーバの基数は、ハイパーサーバの各論理コンピュータ（例えば、各仮想マシン）が冗長的にファイルシステムを管理し、冗長ハイパーボリュームを実装するという点で、その冗長性を定義する。接続性のクラッシュ、損失、および失われたメンバーの置換により、個々の仮想マシンメンバーがハイパーサーバに参加するか、または退出し得るため、ハイパーサーバは、経時的に変動し得る組成を有する。クライアントは、その要求を実行させるように、ハイパーサーバと相互作用し、ハイパーサーバのメンバーシップを認識する必要はない。したがって、クライアントは、どの時点においても、ハイパーサーバのメンバーであるＶＭのＩＰアドレスから抽出するハイパーサーバＩＤを介して、ハイパーサーバをアドレス指定する。

「ハイパーサーバＩＤ（ＨＩＤ）」は、Ｈｙｐｅｒｆｉｌｅｒ内の１つの特定のハイパーサーバを識別する、１６ビットＩＤである。それは、クライアントがその要求のうちのいずれかの標的を識別する方法である。

「ハイパーサーバメンバー（ＨＭ）」は、ハイパーサーバとして協調的に処理するように構成される、論理コンピュータのクラスタ内の論理コンピュータのうちの１つである。これに関する種々の実施形態では、論理コンピュータは、仮想マシンとして実装され、各ＨＭは、仮想マシンである。

「ハイパーサーバテーブル（ＨＴ）」は、Ｈｙｐｅｒｆｉｌｅｒおよびそのクライアントに知られている大域的テーブルであり、ＨＴは、ハイパーサーバ基数に関して（ハイパーサーバが、名前空間のみ、データ空間のみ、または両方にサービス提供するかどうかにかかわらず）、およびハイパーサーバ使用のメンバーであるＶＭのＩＰアドレスに関して、Ｈｙｐｅｒｆｉｌｅｒにおける各ハイパーサーバのメンバーシップを説明する。ＨＴの各エントリは、それが表すハイパーサーバのメンバーシップが変化する度に単調に増加させられる世代番号によって個々に保護される。この番号は、所与のハイパーサーバを標的にする全てのＲＰＣにおいて転送され、この番号は、所与のハイパーサーバが、起こり得る非一貫性を検出すること、および任意の状態ＨＴエントリが必要に応じて更新されることを確認することを可能にする。

「ハイパーボリューム」は、ハイパーサーバによって管理される名前空間およびデータ空間コンポーネントの集合である。それは、そのハイパーボリュームを所有して管理するハイパーサーバと共有されるハイパーサーバＩＤを介して識別される。

「インテントログ」は、バッキングストアへの一セットの更新のリポジトリである。バッキングストアへの一セットの更新が必要とされるときはいつでも、一セットの更新は、各々が関連するテーブルの指示とともに、インテントログにコピーされる。

「論理」コンピュータシステムは、実コンピュータシステムまたは仮想コンピュータシステムのいずれか一方であり得る。論理コンピュータシステムが仮想コンピュータシステムであるとき、仮想コンピュータシステムは、実コンピュータシステムで仮想化ソフトウェアを実行することによって確立される。

「メモリ」という用語は、ランダムアクセスメモリ（ＲＡＭ）または補助メモリを拡張するために使用されるページング等の任意の配列とともに、ＲＡＭおよび補助メモリを意味する。

Ｈｙｐｅｒｆｉｌｅｒにおける「マウント」動作は、クライアントをＨｙｐｅｒｆｉｌｅｒに知らせ、クライアントをＨｙｐｅｒｆｉｌｅｒと相互作用させるために必要とされる全てのデータ構造を取り出し、ローカルマウントポイントの下方の標的Ｈｙｐｅｒｆｉｌｅｒディレクトリ下のファイルシステムツリーを利用可能にする。マウント動作が行われた後、マウントポイント下のファイルおよびディレクトリへの全てのアクセスは、Ｈｙｐｅｒｆｉｌｅｒへの遠隔手続呼び出し要求に変換されるが、それらは、依然として、ローカルファイルシステムに向けられているように見える。マウント動作は、クライアントがＮＦＳサーバ上でディレクトリのマウントを行うときに起こるものに類似する、目的を達成する。

「マウントポイント」は、マウント動作を行う際にクライアントによって選択されるローカルファイルシステム内のディレクトリのパス名である。マウント動作の成功後、マウントポイント下で可視的な全てのファイルは、マウント動作で使用されるファイルシステムの標的ディレクトリに記憶されたファイルおよびディレクトリである。

「名前空間」は、Ｈｙｐｅｒｆｉｌｅｒによって実装される階層的なファイル／ディレクトリ構造を管理する、Ｈｙｐｅｒｆｉｌｅｒの一部である。名前空間全体は、ＨｙｐｅｒｆｉｌｅｒのメンバーであるＨｙｐｅｒｖｅｒｖｅｒにわたって区分化される。ファイルシステム階層とともに、名前空間コンポーネントはまた、ファイルおよびシンボリックリンクに対する第１の範囲のＥＩＤとともに、所有権情報、アクセス許可、作成および修正日等のファイル、ディレクトリ、およびシンボリックリンクの基本属性も記憶する。

「ノードテーブル（ＮＴ）」は、文字列のサイズがＮＴエントリで利用可能な記憶を超えるときの文字列テーブル内の文字列、または文字列のＩＤ、ならびに必要とされる場合、パトリシア木内の接続ＮＴエントリのインデックス、ＮＴエントリに関連するフラグ、および関連ＦＴエントリのインデックスとともに、各ノードのロックを記憶するデータ構造である。ＮＴの２つのエントリは特別であり、エントリ０は、利用可能な名前空間の全てのルートへのポインタの役割を果たす。この間接レベルを有することは、将来、１つの名前空間または複数の名前空間のスナップショットを実装することを可能にし得る。ＮＴのエントリ１は、ＰＯＳＩＸ名前空間のルートディレクトリであり、「Ｉ」に対応する。

「ポリシー」は、一セットの規則であり、この規則は、ファイルの作成において、または記憶層へ、および間接的に、そのような層を実装するデータ空間Ｈｙｐｅｒｆｉｌｅｒへのファイルのデータコンポーネントの割当を伴うファイルの処理において適用される。ポリシーは、ファイルが所与の層内で記憶されるために有する必要のある特性（サフィックス、親ディレクトリ名、所有者）を決定することができる。ポリシーはまた、ほとんど使用されないとき、または大量アクセスが発生しようとしているときに、１つの層から別の層へファイルを移動させるために必要とされるもの等のワークフローを介して行われるべき時間または事象ベースの動作を特定することもできる。

「一次メンバー」は、所与のときに、それが管理するハイパーボリュームの状態に対する権威あるエンティティであり、したがって、ハイパーサーバにおいて主要な役割を実行するハイパーサーバメンバーである。ハイパーサーバ内で、１つの特定のメンバーが、１度に主要な役割を実行する。全ての他のメンバーは、二次メンバーである。一次メンバーは、任意の二次メンバーと同様に、下にあるハイパーボリュームの状態（読み取り動作等）を変更しない任意の要求にサービスを提供することができるが、任意の状態変更要求を行い、二次メンバーに対する動作を調整する１つのメンバーでもある。この配列下で、要求が完了されるときまでに、ハイパーサーバの全てのメンバーは、各個々の要求に関する同一の状態に達する。一次メンバーは、接続性の損失または他の異常挙動により、それがクラッシュするか、またはハイパーサーバから退去させられるまで、その主要な役割を保つ。

「遠隔手続呼び出し（ＲＰＣ）」は、それによってクライアントがＨｙｐｅｒｆｉｌｅｒへのサービスを要求するネットワークプロトコルである。ＲＰＣは、実装される必要がある機能性に合わせられ、ファイルシステムレベルで同期している。プロトコルの下位層は、ＲＰＣの標的であるハイパーサーバに固有の並列性を利用し、必要なときに個々のハイパーサーバメンバーと非同期的に通信するためにそれを活用する。この側面は、呼び出しの意味論を単純化するように、スタックの上層から隠される。

「パッシブディレクトリ」は、親ディレクトリがハッシュ化され、その親のリスト項目およびトラバーサルにおいて適正に報告されるように存在している、ハイパーサーバ上に常駐するディレクトリのバージョンである。Ｈｙｐｅｒｆｉｌｅｒでは、各ディレクトリは、２つのバージョン、すなわち、前述のようなパッシブディレクトリと、各自の名前がハッシュ化される、ハイパーサーバ上に常駐するディレクトリのバージョンであり、ファイルおよびサブディレクトリを作成し、削除し、一覧化し、およびアクセスするために使用されるディレクトリであるアクティブディレクトリとを有し得る。時として、アクティブディレクトリおよびパッシブディレクトリは、同一のハイパーサーバにハッシュ値を持ち、したがって、単一のディレクトリに畳み込まれ得る。

ハイパーサーバの「二次メンバー」は、ハイパーサーバによって管理される下にあるハイパーボリュームの状態を変更しないクライアント要求を実行することができる、ハイパーサーバメンバーである。ファイルへの書き込み、またはファイル作成あるいは削除の場合のように、ハイパーサーバによって管理されるハイパーボリュームの状態が変更されるものであるとき、それは、そのような要求をスレーブとして実行する二次メンバーとそのような動作を発行して調整する、ハイパーサーバの一次メンバーである。ハイパーボリュームの一次メンバーがハイパーボリュームから退出する場合、１つの二次メンバーが主要な役割を果たすように昇進させられる。

「サーバＩＤ（ＳＩＤ）」は、ハイパーサーバ内のハイパーサーバメンバー（ＨＭ）に割り当てられた番号である。各メンバーは、ハイパーサーバに参加するときにそのＳＩＤを受信し、ハイパーサーバから退出するまで、またはクラッシュするときまでにそれを保持する。新しいＨＭは、その時点で未使用であるＳＩＤを受信する（退去させられた、またはクラッシュしたＨＭで使用されていた、以前に使用されたＳＩＤであり得る）。慣例により、ＨＭの最低ＳＩＤは０であり、各連続するＳＩＤは、１、２等である。したがって、ＳＩＤは、ハイパーサーバの基数より常に小さい、小さい数である。

「セット」は、少なくとも１つのメンバーを含む。

「記憶層」は、Ｈｙｐｅｒｆｉｌｅｒにおけるデータ空間ハイパーサーバの高レベルグループ化であり、基数の類似性と、それらが管理するハイパーボリュームを実装するために使用される記憶デバイスの容量および性能の類似性とに基づく。個々のデータ空間ハイパーサーバは、記憶層に割り当てられ、層の属性を受け継ぐ。

「文字列テーブル（ＳＴ）」は、連続した塊に集約することができる、固定長セルで作成されたアレイであり、ノードテーブル内に収まらない文字列を記憶するために使用される。

所与のセットの「サブセット」は、随意に、所与のセット全体を含み得る。

所与のセットの「厳密なサブセット」は、所与のセット全体を含まない。

「仮想コンピュータシステム」（本明細書では時として「仮想マシン」とも呼ばれる）は、任意の下にある実際のハードウェア環境から実質的に独立した様式で実装される、プロセッサ、メモリ、および記憶装置を含む属性を伴う仮想マシンである。

「ワークフロー」は、特定のポリシーを実行するために、または、Ｈｙｐｅｒｆｉｌｅｒのソフトウェアアップグレード、新しいＶＭの追加を通したＨｙｐｅｒｆｉｌｅｒの拡張等の要求された動作を行うために、本明細書の実施形態による記憶システムによって編成される一セットの動作である。

ＨＹＰＥＲＦＩＬＥＲは、広範囲のハードウェア環境でスケーラブル高性能ファイルサーバを実装するソフトウェアに対する本明細書の出願人であるＰｅａｘｙ，Ｉｎｃ．の商標である。本明細書で使用される場合、「Ｈｙｐｅｒｆｉｌｅｒ」という用語は、従来のコンピュータハードウェア環境で作動し、単一の名前空間内のファイル記憶のためのスケーラブル設備を提供するように動的に拡張されることが可能な分散型ファイルシステムのコンポーネントとして、本明細書では「ハイパーサーバ」と呼ばれる１つ以上の高可用性ミニクラスタを確立する、Ｐｅａｘｙによって開発された、そのようなソフトウェアの特定の実施例を指す。

本明細書の実施形態における、Ｈｙｐｅｒｆｉｌｅｒおよびそのコンポーネントハイパーサーバは、ファイルへのＰＯＳＩＸアクセスを提供し、それらは、ＤＢ型作業負荷をサポートするように意図されていない。

一実施形態では、Ｈｙｐｅｒｆｉｌｅｒは、Ｌｉｎｕｘ（登録商標）マシンをクライアントとしてサポートする。他の実施形態が、Ｍｉｃｒｏｓｏｆｔ（Ｒｅｄｍｏｎｄ，Ｗａｓｈｉｎｇｔｏｎ）によって提供されるＷｉｎｄｏｗｓ（登録商標）オペレーティングシステム等の他のオペレーティングシステムのクライアントをサポートするように確立され得る。

本明細書で詳細に説明されるＨｙｐｅｒｆｉｌｅｒの実施形態内で使用されるファイル記憶装置アクセスプロトコルは、高度に効率化され、ＵＤＰに基づく。基本的ファイルサービスを使用するクライアントは、Ｈｙｐｅｒｆｉｌｅｒと連動する動的にロード可能なＬｉｎｕｘ（登録商標）モジュールを配備する必要がある。これは、低侵襲性であり、極めて限定されたローカルホストリソースを使用する、非常に軽量のクライアントである。

ＰＯＳＩＸファイルシステムインターフェースに加えて、ファイルにアクセスするためのスケーラブルＨＴＴＰ／ＨＴＴＰＳインターフェースもまた、この実施形態のために提供される。

以下では、主要な副次的コンポーネントの全ての詳細を挙げることによって、アーキテクチャの説明を提供する。アーキテクチャの説明は、以下の主要な節で提供される。
Ｉ．Ｈｙｐｅｒｆｉｌｅｒの物理的基盤
ＩＩ．主要Ｈｙｐｅｒｆｉｌｅｒ抽象概念
ＩＩＩ．動作挙動
（Ｉ．Ｈｙｐｅｒｆｉｌｅｒの物理的基盤）
本発明の種々の実施形態では、Ｈｙｐｅｒｆｉｌｅｒは、クライアントコンピュータからの記憶要求に応答するように構成される１つ以上のハイパーサーバによって実装され、各ハイパーサーバは、ハイパーサーバメンバー（ＨＭ）として動作する、１つ以上の論理コンピュータのクラスタとして実装される。順に、本発明の実施形態では、ハイパーサーバメンバーとして動作する各論理コンピュータは、そのＣＰＵ、ＲＡＭ、およびネットワークリソースが、ＫＶＭ、ＶＭｗａｒｅ、Ｘｅｎ等のハイパーバイザによって仮想化される、物理的コンピュータ上で作動する仮想マシン（ＶＭ）として実装される。

システム管理コンポーネントは、高可用性サーバ抽象概念を実装するハイパーサーバにＨＭを一緒にクラスタ化する。加えて、システム管理ソフトウェアは、Ｈｙｐｅｒｆｉｌｅｒとして知られているソフトウェア抽象概念にハイパーサーバを集約する。

Ｈｙｐｅｒｆｉｌｅｒのクライアントは、Ｈｙｐｅｒｆｉｌｅｒファイルシステムがマウントされ、従来のＰＯＳＩＸプログラミングＡＰＩを介してアクセスされることを可能にするソフトウェアコンポーネントを作動させる（「マウント」動作は、ＮＦＳファイラへのアクセスを獲得するために行われるものに本質的に類似する）。

各ＨＭは、ハードウェアで利用可能であるか、または下にあるハイパーバイザ（存在する場合）によって仮想化される、利用可能な記憶装置、ＣＰＵ、ＲＡＭ、およびネットワークリソースを有する。

（記憶装置）
分散型ファイル記憶装置をサポートするために、各ＨＭは、ブロック記憶装置の使用を利用可能にする。これは、異なる方法で実装されることができる。

ＨＭは、ＳＡＮインフラストラクチャを通してＬＵＮの使用を利用可能にすることができる。これは、厳密に言えば、ＳＡＮである必要はないことに留意されたい。実際のＳＡＮに加えて、そのＶＳＡＮ製品を介してＶＭｗａｒｅによって、または、Ｃｏｒａｉｄ、Ｎｉｍｂｌｅ、Ｔｉｎｔｒｉ等の企業によって提供される記憶設備等のＶＭ用の記憶装置を提供する、ＳＡＮのような設備をサポートする複数の代替案が存在する。採用される特定の記憶設備にかかわらず、ＨＭレベルでの記憶装置は、ＳＡＮによって利用可能にされるＬＵＮに類似すると考えられる。そのようなＬＵＮがある形態の冗長性を実装するとき、このタイプの記憶装置は、高可用性属性を提供することができる。しかしながら、下にあるＬＵＮは、冗長であり、記憶装置レベルで高い可用性（ＨＡ）をサポートすることが可能であろうが、これらのＬＵＮを管理し、ファイルおよびディレクトリの形態で記憶コンテンツを示す、サーバソフトウェアが、それ自体、冗長ＨＭ上で作動することが可能ではない限り、ＨＭのクラッシュは、ＨＭが管理するＬＵＮに記憶されたデータへのアクセスを損なうであろう。したがって、下にある記憶装置の冗長性およびＨＡ属性にかかわらず、Ｈｙｐｅｒｆｉｌｅｒは、ＨＭにおける冗長性がサポートされるような方法で構築されなければならない。

異なるアプローチは、物理的記憶装置を業界標準コンピュータ内で作動するＨＭに関連付けて、ＨＭ用の記憶装置としてコンピュータ内のディスクドライバを使用するものである。この場合、別個のＨＭに、コンピュータ内のドライブの各々を管理させることができる。以前のアプローチとの違いは、この場合、ＨｙｐｅｒｆｉｌｅｒソフトウェアがＨＭおよび下にある記憶装置の両方において冗長性をサポートするための用意をしなければならないことである。

上記の２つのアプローチは、実際の結果に関して極めて異なる。典型的な実施形態では、ＨＭが、それらが作動するマシン内の物理的ディスクドライブを直接管理する場合、複数のＨＭにわたる記憶複製方式が実装されて。明らかに、冗長性およびＨＡが、記憶リソースを供給するＳＡＮまたはＳＡＮのような設備によって提供される場合、これは、厳密には必要ではない。必要とされるとき、顧客は、所望される複製の程度を選択することによって、複製を構成することができる（以下参照）。複製は、ミラーリングとして実装され、アクティブデータを含む記憶デバイスの一部に限定されることに留意されたい。これは、ミラーにわたる再同期化を加速し、再同期化が起こっている場合でさえも性能を大幅に向上させる。

ＨＭは、ほとんど記憶装置に依存せず、ＳＳＤを含む任意のタイプの物理的媒体をサポートすることができる。

典型的には、ハイパーサーバ内の任意の個々のＨＭが、２つの別個の記憶パーティションを管理し、１つは、名前空間専用であり、１つは、データ空間専用である。これは、これから先でさらに詳細に説明されるであろうが、基本概念のうちの１つは、特定の配備のために顧客が必要とする性能を最も良く達成することができる、物理的媒体上に名前空間およびデータ空間を配置することが可能であることである。これは、より高速のデバイスをキャッシングに専念させるよりも良好である。なぜなら、アクセスされている一セットのファイルが極めてランダムであるときはいつでも（本発明の実施形態が適用可能である１つの使用事例のように）、この方式が有効ではないであろうからである。

（ＣＰＵおよびメモリ）
ＨＭは、マルチコアＣＰＵを利用するシステム上で作動することが期待される。Ｈｙｐｅｒｆｉｌｅｒ設計で行われる選択の多くは、必要に応じてＩ／Ｏ帯域幅のための処理を交換することによって、マルチコアアーキテクチャの処理能力を利用する。

メモリに関しては、Ｈｙｐｅｒｆｉｌｅｒは、サービス提供することを目標とする市場区分の制約内で、非常に異なるタイプの負荷をサポートするように設計されている。したがって、各ＨＭが使用することを可能にされるべきであるＲＡＭの量は、所望される性能と各展開のための費用目標との関数である。しかしながら、一般に、各ＨＭは、利用可能な１〜４ギガバイトのＲＡＭを有すべきであると期待される。

（ネットワーク）
Ｈｙｐｅｒｆｉｌｅｒは、Ｅｔｈｅｒｎｅｔ（登録商標）を経由したＩＰ以外のいかなる特別なタイプのネットワーク接続にも依存しない。これは、費用を低減させ、非常に一般的な技術へのアクセスを可能にし、複数のタイプのネットワークインフラストラクチャを管理する必要性を回避し、これは再度、総所有コスト（ＴＣＯ）を削減する。

業界標準サーバで利用可能である典型的なネットワークインターフェースカード（ＮＩＣ）は、この仕事に完璧に適している。しかしながら、１つの重要な警告が指摘される。すなわち、同一のボックス内で動作するＨＭが、ＣＰＵコアおよびＮＩＣを共有し、したがって、これらが平衡を保たれることが極めて望ましい。例えば、１６個のディスクドライブをホストする（おそらく１６個のＨＭを作動させる）コンピュータは、その役割が、ドライブのコンテンツへのアクセスが低頻度であると見なされる、記憶階層内の下層の役割ではない限り、全ての対のＨＭに対して１ギガビット／秒以上のＮＩＣポートを利用可能にすべきである。

（追加のハードウェア要件）
Ｈｙｐｅｒｆｉｌｅｒは、いかなる他の特別なタイプのハードウェアの存在も決定付けないが、ＮＶＲＡＭ等のものを確実に利用することができる。

図１は、本発明の実施形態による、Ｈｙｐｅｒｆｉｌｅｒのブロック図である。Ｈｙｐｅｒｆｉｌｅｒ１０１は、ここでは、Ｈｙｐｅｒｆｉｌｅｒ１０１に関連付けられる名前空間１０４を取り扱うための名前空間ハイパーサーバ１０６、１０７、および１０８の集合によって、および同じ名前空間に対応するデータ空間１０５を取り扱うためのデータ空間ハイパーサーバ１２１、１２２、１２３、１２４、および１２５の集合によって、実装される。本実施例では、各名前空間ハイパーサーバは、２つのハイパーサーバメンバー（ＨＭ）によって実装され、各ハイパーサーバメンバーは、仮想マシン（ＶＭ）である。したがって、名前空間ハイパーサーバ１０６は、ＶＭ１０９およびＶＭ１１０によって実装され、名前空間ハイパーサーバ１０７は、ＶＭ１１１およびＶＭ１１２によって実装される。同様に、本実施例での各データ空間ハイパーサーバは、３つのハイパーサーバメンバー（ＨＭ）によって実装され、各ハイパーサーバメンバーは、ＶＭである。したがって、データ空間ハイパーサーバ１２１は、ＶＭ１２６、１２７、および１２８によって実装される（他のＨｙｐｅｒｆｉｌｅｒ１０２および１０３は、単一のＨｙｐｅｒｆｉｌｅｒの性能が不十分と見なされるときに大規模記憶装置アクセスさえも提供するように追加できることを示すために図示されている）。

ハイパーサーバ内のＶＭは、１１３、１１４、１１５、および１１６として示されるものを含む、一連の従来のサーバで作動するソフトウェアによって確立される。好適な冗長性を提供するために、所与のハイパーサーバ内の各ＶＭが、異なる物理的サーバで実装される。したがって、名前空間ハイパーサーバ１０６のＶＭ１０９および１１０は、異なる物理的サーバ１１３および１１４で実装される。同様に、名前空間ハイパーサーバ１０７のＶＭ１１１および１１２もまた、異なる物理的サーバ１１３および１１４で実装される。データ空間ハイパーサーバ１２１に関して、その３つのＶＭ１２６、１２７、および１２８は、それぞれ、異なる物理的サーバ１１３、１１４、および１１５で実装される。

また、物理的サーバが同一である必要はないことも図１から明白である。実際、例えば、サーバ１１３、１１４、および１１５は、第１層記憶装置に使用され、サーバ１１６を含むサーバは、第２層記憶装置に使用される。最終的に、本実施例におけるサーバ１３１および１３２は、クラウドベースのサーバであり、データ空間ハイパーサーバ１２５によってインターネットを経由してアクセスされ、低頻度でアクセスされるデータに使用され、アクセスにおける待ち時間は、あまり重要ではないと見なされる。

（ＩＩ．主要Ｈｙｐｅｒｆｉｌｅｒ抽象概念）
この節は、本システムが実装する主要抽象概念、およびそれらが下にある物理デバイスに関する方法を説明することによって、前の節を踏まえる。

（ハイパーボリュームおよびハイパーサーバ）
ハイパーボリュームは、物理的記憶媒体の上に複製された高可用性記憶装置を構築し、ネットワークにわたって記憶デバイスをアドレス指定する方法を提供する、抽象概念である。本質的に、ハイパーボリュームを、ハイパーサーバの全てのメンバーにわたって実装される記憶装置の冗長論理ボリュームと考えることができる。（単一のメンバーを伴うハイパーサーバの特別な場合において、概して、ＳＡＮ ＬＵＮの場合のように、使用される物理的記憶装置自体がブロックレベルで冗長ではない限り、ハイパーボリュームはいかなる冗長性も提供しないであろう。）（この抽象概念は、本システムが提供する総合的見解の一部である、より管理可能な要素にＨｙｐｅｒｆｉｌｅｒにおける記憶装置を区分化するために使用される。）各ハイパーサーバは、そのＨＭを通して専用ハイパーボリュームにアクセスして管理する。

ＳＡＮ内のＬＵＮの場合のように、冗長ブロック記憶装置の場合でさえも、ハイパーボリュームは、追加の冗長性を構築することができるが、これは必要ではなく、おそらく、記憶リソースの無駄をもたらすであろう。

複数のＨＭにわたって物理的ボリュームのコンテンツを複製することによってハイパーボリュームが構築されると、そのＨＭを通して、ハイパーサーバは、全ての複製がロックステップにおいて進展することを確認する。

ハイパーボリュームは、Ｈｙｐｅｒｆｉｌｅｒの２つの別個のコンポーネントが常駐し得る、リポジトリである。それらは、以下である。
・名前空間コンポーネント。
・データ空間コンポーネント。

２つのコンポーネントのうちの少なくとも１つが、ハイパーボリュームの一部でなくてはならないことに留意されたい。しかしながら、両方のコンポーネントが常に存在する必要はなく、これは、Ｈｙｐｅｒｆｉｌｅｒの動作および管理において高レベルの融通性を可能にする。

ハイパーサーバがハイパーボリュームのアクティブマネージャであり、ハイパーボリュームがハイパーサーバの専用のための潜在的に冗長な記憶リソースであるため、ハイパーボリュームおよびハイパーサーバは連動する。したがって、ハイパーボリュームの状態を変更する（ファイルまたはディレクトリを作成または削除する、あるいはファイルに書き込む）ために、クライアントは、適切な要求をハイパーサーバに送信しなければならない。

本システムは、整数識別子を各ハイパーボリューム／ハイパーサーバに割り当て（ハイパーボリュームＩＤまたはＨＩＤ）、そのようなコンポーネントの全てのアドレス指定は、そのような識別子を通して行われる（同一のＩＤがハイパーサーバおよびそのハイパーボリュームを識別する）。これは、ハイパーサーバ内の１つのＨＭの損失が、データまたはメタデータにアクセスしようとするクライアントに常に透過的であるように、所与のハイパーボリューム／ハイパーサーバの物理的メンバーの情報から通信側面を分断することを可能にする。また、ＨＭが故障または他の理由により交換されると、ハイパーサーバ全体の利用停止を伴う壊滅的損失が起こらない限り、サービスのクライアントは、これの全てを認識しないままとなる。（この性質の事象は、Ｈｙｐｅｒｆｉｌｅｒが提供する高い程度の冗長性により、起こることが期待されない）。

ハイパーサーバ内のＨＭの数は、ハイパーサーバの「基数」と呼ばれる。（これはまた、下にあるハイパーボリュームの属性でもあり、ハイパーボリュームは、それが属するハイパーサーバの基数と同数の複製を有する。）

これは、ハイパーサーバが最初に構成されるときに選択される。これは、後で変更されることができる。しかしながら、基数は、常に、実装することを選択する冗長性のレベルに応じて、１〜４の範囲内の小さい数である。各個々のハイパーサーバは、異なる基数を提供するように構成されることができることに留意されたい。

各ＨＭは、サーバＩＤ（ＳＩＤ）を割り当てられる。慣例により、割り当てられる第１のＳＩＤがＳＩＤ＝０であるため、ＳＩＤは、常に、ハイパーサーバの基数より小さい、小さい数である。各メンバーは、ハイパーサーバに再参加するときにそのＳＩＤを受信し、ハイパーサーバから退出するまで、またはクラッシュする場合まで、それを保持する。新しいＨＭは、その時点で未使用であるＳＩＤを受信する（退去させられた、またはクラッシュしたＨＭで使用されていた、以前に使用されたＳＩＤであり得る）。

任意のハイパーサーバ内で、１つのメンバーは、常に一次メンバーであるように選択される。このメンバーは、データまたはメタデータにおける状態の変化を伴う任意の要求を仲裁するので、特別な立場を有する。

ハイパーサーバの一次メンバーが任意の理由でクラッシュするか、またはダウンするとき、ハイパーサーバの別のメンバーが主要な役割を引き継ぎ、利用可能である場合、欠落しているメンバーＨＭに取って代わるように、システム管理ソフトウェアによって、新しいＨＭが自動的にもたらされる。どのハイパーサーバメンバーが主要な役割を引き継ぐであろうかという選択は、選択が決定論的であり、個々のメンバーの状態属性に基づくため、選択プロセスを必要としない。いかなるＨＭも主要な役割を引き継ぐために利用可能ではない場合、ハイパーサーバは、劣化モードで動作し続ける。

主要メンバーになる二次ＨＭは、そのＳＩＤを保持し続けることに留意されたい。

ＨＭは、以下の遷移のみを行うことができる。
・非メンバーから一次または二次メンバーへ。
・二次メンバーから一次メンバーへ。
・一次または二次メンバーから非メンバーへ。この最後の遷移は、メンバーがクラッシュする場合に自動的に起こるか、またはその一貫しない状態の検出によって引き起こされるメンバーの退去によって引き起こされ得る。

いかなる状況でも、退去させられるか、クラッシュしない限り、一次メンバーは、その役割を放棄し、二次メンバーになることができないことに留意されたい。

クライアントが要求をＨｙｐｅｒｆｉｌｅｒに送信するとき、これは、名前空間要求またはデータ要求のいずれか一方である。名前空間要求は、パス名を伴い、そのパス名を管理しているハイパーサーバに送信されなければならないものである。パス名と関連ハイパーサーバとの間のマッピングは、これから先に説明される機構を介して起こる。データ要求は、標的ハイパーサーバのＨＩＤを含むハンドルに基づいて動作するため、自己識別する。

ハイパーサーバへの２つのタイプの着信要求がある。
・読み取り型要求：このカテゴリにおける任意の要求が行われた後、ハイパーボリューム内のデータまたはメタデータの状態は変化していない。このタイプの要求は、ファイル読み取り、ディレクトリ一覧、ファイルメタデータの取り出し等を含む。
・書き込み型要求：このクラスにおける要求は、ハイパーボリューム内のデータまたはメタデータへの変更を引き起こす。このカテゴリにおける要求は、ファイル書き込み、ファイル作成または名前変更等である。

ハイパーサーバの任意の個々のメンバーが、任意の読み取り型要求を取り扱うことができる。ハイパーサーバに送信される要求は、負荷を区分化するよう、そのメンバーの間で分配される。本システムは、ファイルデータの任意のローカルキャッシングを活用するように、特定のファイル範囲に関する要求を処理するメンバーが、常に同じメンバーであることを確認する。本システムは、クライアントに利用可能な要素、すなわち、パス名ベースの要求についてはパス名、ＩＤベースの要求についてはファイルのＩＤに基づいて、クライアントにおける読み取り型要求の分配をアルゴリズムで達成する。

全ての他のメンバーが行うように読み取り型要求にサービスを提供することに加えて、一次メンバーはまた、書き込み型要求の処理を調整することを担当する。一次メンバーは、そのような要求が完了したときに全てのメンバーが依然として同期化されていることを確認しなければならず、準拠することまたは再同期化されることができなかったハイパーサーバのメンバーを修復および再同期化するか、退去させるかが可能でなければならない。したがって、一次メンバーは、全てのメンバーが要求の実行の完了に成功したときのみ、肯定確認をクライアントに返す。代替として、本システムが構成される方法に応じて、一次メンバーは、ハイパーサーバのメンバーの大多数が動作を実行したときに確認を返し得る。後者の場合、トランザクションを完了することができなかったメンバーは、適正に標識され、トランザクションが遅延した様式で完了されるか、またはメンバーがハイパーサーバから退去させられる。

Ｈｙｐｅｒｆｉｌｅｒが可変数のハイパーサーバを集約し、ハイパーサーバが同じコンテンツを複製するので、効率的なＨｙｐｅｒｆｉｌｅｒ動作は、所与のハイパーサーバ内の効率的な相互作用のみに依存する。実際、書き込み型要求（ハイパーボリューム状態を変更するため、調整を必要とする唯一のタイプ）を調整するために必要とされる通信の量は、最小限である。結果として、Ｈｙｐｅｒｆｉｌｅｒは無制限に拡張することができる。なぜなら、要求が実行される迅速性は、全体的なＨｙｐｅｒｆｉｌｅｒサイズの関数ではなく、本質的に小さいハイパーサーバサイズの関数でしかないからである。したがって、Ｈｙｐｅｒｆｉｌｅｒは、ハイパーサーバの連合として挙動し、性能は、Ｈｙｐｅｒｆｉｌｅｒサイズとともに直線的に拡大縮小する。

ファイル動作に対するＩＤベースの要求は、ハイパーボリューム内に記憶され、ＨＩＤを含む一意のＩＤを介して識別されるファイルセグメント（範囲）に作用する。したがって、各そのような範囲ＩＤは、常に、Ｈｙｐｅｒｆｉｌｅｒ全体にわたって大域的に一意である。

ドライブまたはノードが故障し、関連ＨＭがそれとともに故障するとき、利用可能である場合、システム管理が置換用ＨＭを取り込む。これは、ハイパーサーバメンバーと通信するために使用される、ＨＩＤと下にあるＩＰアドレスとの間のマッピングを置換することを伴う。次いで、ハイパーボリュームの存続メンバーに記憶されたデータは、新しいメンバーとしてハイパーボリュームに参加する新しいＨＭに複製される（データ自体が固有の記憶冗長性を提供するＳＡＮまたはＳＡＮのような設備にすでに依存していない限り）。新しいメンバーが残りのハイパーサーバと同期化されると、それは、そのピアとともに、着信要求にサービスを提供し始める。

基数が、関連ハイパーボリュームが提供する複製のレベルを定義するので、同一のＨｙｐｅｒｆｉｌｅｒ内の異なるハイパーサーバに異なる基数を割り当てる能力は、いくつかの利点を有する。どのハイパーサーバ（およびハイパーボリューム）が所与のファイルをホストするかを選択することによって、本システムは、より高いまたは低い固有の冗長性をファイルデータに割り当てることを可能にする。これは、より高いまたは低いレベルの冗長性を与えられるべきであるファイルを顧客に選別させ、したがって、あるデータが顧客に対して有する重要性に基づいて、利用可能な記憶装置の最適な割り付けを可能にする。所望のレベルの冗長性への割り付けは、ファイルが常駐するディレクトリ、またはファイルのサフィックスに基づく等、他の基準に従って、行われることができる。代替として、単純化した実施形態では、全てのハイパーサーバの基数は、単一のＨｙｐｅｒｆｉｌｅｒ全体に及ぶ値に制限される。

（ネットワーク層）
ネットワーク層は、Ｈｙｐｅｒｆｉｌｅｒファイル記憶プロトコルを実装することに関与する。プロトコルは、ＴＣＰよりもむしろＵＤＰに基づく。これは、いくつかの利点を有する。
・これは、通信が効率化され、非常に効率的になることを可能にする。
・これは、接続指向相互作用に依存しない。これは、オーバーヘッドを削減し、エンドツーエンド意味論の実装を単純化し、かつ、ネットワーク中断、および要求に返信するエンティティが要求が送信されるべきであったものとは異なる場合により良好に対処するので、有利である。（例えば、後者が異なるメンバーによって完了されることを成功できた場合、要求に対処していたハイパーサーバメンバーにおけるエラーを克服するために非常に有用である。）
一方で、これはまた、メッセージのシークエンシング、保証された送達、非重複等に適正に対処するために、遠隔手続呼び出し（ＲＰＣ）層が純トランスポートの上に実装されることをも要求する。

Ｈｙｐｅｒｆｉｌｅｒファイルシステムの上層は、同期要求に関してハイパーサーバに対処し、前の副次節で記述されるように、ハイパーサーバメンバーに関連付けられるＩＰアドレスも個々のハイパーサーバの基数も認識する必要がない。それでもなお、ネットワーク設備の下層は、ハイパーサーバのメンバーである特定のＩＰアドレスへのユニキャストメッセージに関して通信に対処し、非同期機構を使用することによって同期ネットワーク意味論を下に実装する。これは、より低いレベルで非同期並列ネットワークＩ／Ｏの融通性および効率に依存しながら、分散ファイルシステム層における論理を単純化する。

ネットワーク層を呼び出すファイルシステム層は、ハイパーサーバのメンバーのうちのいずれに任意の所与のメッセージが送信されるべきかを特定することができる。これは、達成される動作に応じて、２つの方法で行うことができる。

クライアントがその要求を一次メンバー二次メンバー、全ての二次メンバー、またはハイパーサーバの全てのメンバーに送信することを所望する場合、クライアントは、上記の場合のうちのいずれかを特定することを可能にされる。

代替として、ビットマップに基づいて、クライアントは、所与の要求の標的がメンバーのうちの１つ以上であるかどうかを特定することができる。各メンバーは、メンバーがハイパーサーバに属する限り保持され、そのインデックスを使用していたメンバーがハイパーサーバメンバーシップから退出するときに新しいメンバーに再割り当てさられるのみである内部ハイパーサーバインデックスを受信するので、これは、目的とするメンバーを明白に識別する。また、ビットマップがこの目的で使用されるため、１つだけ、いくつか、または全てのメンバーをこのようにしてアドレス指定することができることにも留意されたい。

これは、ネットワーク層に送信される各要求がフラグを含むことを伴い、フラッグは、２つのアドレス指定モードのうちのいずれがその要求に使用されるか、および前者に基づいて、メンバーのうちのいずれが選択される形式に従って標的にされるかを識別する。

また、要求クライアントによって受信される任意の返信は、返信したメンバーのインデックスを用いて識別されることにも留意されたい。ネットワーク層が、同期高レベル要求を選択された受信者への非同期要求へマップするので、複数の返信がある場合、この同じ層が全てのそのような返信を単一の集約返信に組み立てることに留意されたい。返信の各セグメントは、返信したメンバー（およびその役割）のインデックスを搬送する。

ネットワーク層はまた、Ｈｙｐｅｒｆｉｌｅｒのクライアント内でサーバ設備を実装する。クライアント側で提供されるサービスは、非常に最小限で単純であるが、有用であり、クライアントが依然としてアクティブであるかどうか、またはそれらが取得したあるオブジェクトが依然として使用中であるかどうかを立証し、本システムの融通性を増進する。

Ｈｙｐｅｒｆｉｌｅｒでは、ファイルシステム層は、以下の様式でクライアント要求を実行する。

クライアントは、Ｈｙｐｅｒｆｉｌｅｒ名前空間をローカルマウントポイント（空であり、その下でクライアントがＨｙｐｅｒｆｉｌｅｒの名前空間を参照し、それにアクセスすると考えられるであろうローカルディレクトリ）にマウントする。マウントは、マウントに関与するＨｙｐｅｒｆｉｌｅｒ全体に及ぶ周知のエンティティにアドレス指定される。これは、本システムが起動するときに単一のハイパーサーバに要求が殺到することを防止するために、複製エンティティであることができることに留意されたい。マウントが行われるとき、クライアントは、Ｈｙｐｅｒｆｉｌｅｒから、Ｈｙｐｅｒｆｉｌｅｒの組成を表すデータ構造を受信する。これらは、ハッシュバケットをハイパーサーバにマップするハッシュテーブル、Ｈｙｐｅｒｆｉｌｅｒにおけるハイパーサーバの数、および各ハイパーサーバのメンバーシップを表すテーブルを含む。

ファイルシステム動作が必要とされるとき、クライアント内のファイルシステム層は、適切な要求を下層に送信する。要求の性質は、必要とされる相互作用のタイプを決定する。ファイルを開くことなどの名前関連要求は、パス名が６４ビット数にハッシュ化されることをもたらす。次いで、番号が、その中にハイパーサーバＩＤが記憶されているハッシュテーブルにおける１つの特定のスロットをアドレス指定するために使用される。これは、クライアントがその要求をアドレス指定すべきハイパーサーバの指示を下のクライアント層に与える。

次いで、要求は、特定ハイパーサーバにアドレス指定されるために、ネットワーク層に送信される。ネットワーク層は、ハイパーサーバＩＤをそのメンバーのうちの１つのＩＰアドレスに変換し、要求を適切なハイパーサーバメンバーに送信する。これは、返信を待ち、これが起こるときに、返信はファイルシステムの上層に転送される。

これに関して、全体として考慮されるべき複数の事情がある。最初に、Ｈｙｐｅｒｆｉｌｅｒが経時的に進展する。これは、ハイパーサーバの数が増大し得ること、ハイパーサーバ内のメンバーＨＭの総数が変化し得ること、および、ＨＭがクラッシュして交換され得ることをも意味する。これは全て、ハッシュテーブル、ならびに各ハイパーサーバの組成に対する変更を引き起こし得る。この理由により、ハッシュテーブル、およびハイパーサーバを表す各テーブルは、単調に増加する関連世代番号を有する。ハッシュテーブルが修正される度に、この番号は昇進させられる。任意のＲＰＣは、使用されるハッシュテーブルの世代番号、およびＲＰＣが向けられるハイパーサーバの世代番号を搬送する。これは、受信端におけるエンティティが、更新を必要とすることをクライアントに知らせることによって旧世代番号を搬送する任意の要求に反応することを可能にする。これは、非常に非同期的かつ漸進的な様式で、ハッシュテーブルおよびハイパーサーバ組成が必要に応じて伝搬されることを可能にする。

Ｈｙｐｅｒｆｉｌｅｒのシステム管理コンポーネントは、ハッシュテーブルおよびその世代番号、ならびに個々の世代番号を伴うハイパーサーバ構成を維持することに関与する。

（Ｈｙｐｅｒｆｉｌｅｒ名前空間）
本明細書の種々の実施形態によるシステムの名前空間は、完全に分散されている。Ｈｙｐｅｒｆｉｌｅｒクライアントは、ファイルまたはディレクトリのパス名に基づいて所与のファイルまたはディレクトリを管理するハイパーサーバのＨＩＤを識別することができる。これは、任意のファイルシステムオブジェクトにアクセスするために、任意のクライアントが、通信する必要があるハイパーサーバを知ることを可能にする。ＨＩＤへのパス名のマッピングは、ハッシングを介して達成される。本質的に、各Ｈｙｐｅｒｆｉｌｅｒクライアントは、ＮＦＳのために行うであろう同程度に、クライアント自体にローカルであるディレクトリ上でＨｙｐｅｒｆｉｌｅｒの「マウント」動作を行う。マウントのときに、クライアントは、２つのテーブル、ハイパーサーバテーブル（ＨＴ）、およびディレクトリハッシュテーブル（ＤＨＴ）を含む、ある量のＨｙｐｅｒｆｉｌｅｒ情報を取り出す。

ハイパーサーバテーブル（ＨＴ）は、Ｈｙｐｅｒｆｉｌｅｒで利用可能な全てのハイパーサーバをそれらの組成とともに一覧化する。これは、ＨＩＤとハイパーサーバのメンバーのＩＰアドレスとの間のマッピングを提供する。下にあるネットワーク層は、Ｈｙｐｅｒｆｉｌｅｒクライアントがハイパーサーバメンバーと相互作用することを可能にするこのテーブルの一次ユーザである。前述のように、ハイパーサーバ世代番号は、各ハイパーサーバ構成を保護する。これは、各ハイパーサーバ内の構成変更を追跡することを可能にする。ネットワーク層が、ハイパーサーバに送信される各メッセージ内にこの世代番号を自動的に挿入するので、ハイパーサーバは、世代番号の任意の非一貫性を診断することができ、したがって、ＨＴのそのコピーをリフレッシュする必要があることをクライアントに警告することができる。Ｈｙｐｅｒｆｉｌｅｒに対して変更が適用されるときはいつでも（例えば、ＨＭがクラッシュするかアクセス不可能になるとき、または新しいＨＭがＨｙｐｅｒｆｉｌｅｒにアタッチされる場合）、ＨＴ内のエントリが変化することに留意されたい。

ディレクトリハッシュテーブル（ＤＨＴ）は、ディレクトリをＨＩＤにマップする。概念的観点から、これは、単に、各々がハイパーサーバのＩＤを含むスロットのアレイである。マッピングは、多数対１であり、これは、一般に、複数のスロットが同一のハイパーサーバを指し示すであろうことを意味する。クライアントがパス名を解決する必要があるとき、それは、Ｈｙｐｅｒｆｉｌｅｒ上の絶対パス名（目的とするファイルシステムオブジェクトの親ディレクトリまで（親ディレクトリを含む））をＤＨＴ内の１つのエントリにハッシュ化する。このエントリは、ディレクトリを管理しており、そのディレクトリ内のオブジェクトに対する任意の要求が送信されるべきハイパーサーバのＨＩＤを提供する。ＤＨＴは、Ｈｙｐｅｒｆｉｌｅｒ状態とそのクライアントの状態との間の任意の非一貫性の検出を可能にするように、それ自体が世代番号によって保護される。したがって、そのような非一貫性は、検出されるとすぐに、オンザフライで修復されることができ、それらは、目的とするＤＨＴエントリが使用されているときに検出されることができるため危険ではない。ハッシングの本質により、単一のＤＨＴエントリは、複数のディレクトリをマップする。また、ＤＨＴは、複数のＤＨＴエントリが同一のハイパーサーバを指し示すことができるように、ＨＴより多くのエントリを含むことが期待される。発想としては、１００：１の比がＤＨＴスロットの数とハイパーサーバの数との間に存在すべきである。これは、例えば、ボトルネックを緩和するように、またはハイパーサーバにわたるＤＨＴエントリの再分配が必要とされるときに、１つのハイパーサーバから別のハイパーサーバへの特定のエントリ（および関連ディレクトリ）の再標的化を可能にする。

両方のテーブルは、Ｈｙｐｅｒｆｉｌｅｒにおけるハイパーサーバの数に敏感であることに留意されたい。この数が動的に変動し得るので、テーブルは、適切であるときに更新される必要がある。Ｈｙｐｅｒｆｉｌｅｒ側では、ＨＴは、ハイパーサーバの組成の変化が起こる度に更新される。クライアント側では、これは、クライアントが、世代番号が変化したハイパーサーバを使用しているときのみ必要とされる。

ＤＨＴは、新しいハイパーサーバがＨｙｐｅｒｆｉｌｅｒに追加されるときに更新されることができる。新しいハイパーサーバが追加された後に、たとえＤＨＴが更新されなくても、Ｈｙｐｅｒｆｉｌｅｒがその機能を実行し続けることができるという意味で、これは強制的ではないことに留意されたい。この場合、新しいハイパーサーバは、依然としてデータファイルを記憶することができるであろうが、名前空間の分配に参加しないであろう。これは、（上層ハイパーサーバの場合は）過渡状態であり得るが、（データファイルのみを記憶する）下層ハイパーサーバの永久状態であり得ることに留意されたい。

ＤＨＴはまた、１つの重要な性質を満たさなければならない。それが拡張されるとき、ハッシングスキームは、拡張後にテーブルエントリが意図的に変更されない限り、拡張前にハッシングを介して取り出されるＨＩＤが、拡張後に取り出されるＨＩＤと同一でなければならないようなものでなければならない。これを明確にするために、所与のディレクトリ名をハッシュ化することによって、拡張前にＤＨＴから取り出されるＨＩＤがＮであり、次いで、ＤＨＴがサイズを拡張される場合、拡張が完了した後に、同一のディレクトリが依然としてＮをもたらさなければならないことを想定されたい。しかしながら、テーブル拡張が完了した後、本システムは、必要であれば、より一様な分配を提供するように、エントリにわたってＨＩＤを再分配することを可能にされることに留意されたい。しかしながら、これはまた、置換されているハイパーサーバによって以前に管理されたディレクトリを、引き継いでいるハイパーサーバに移動させることを伴う。したがって、ＤＨＴ拡張を用いてマッピングを保持する場合、ディレクトリの移動、これへのハイパーサーバの積極的な関与を必要とする動作は、あるＤＨＴエントリが置換されるときに行われる必要があるのみである。

（記憶装置クラス）
メタデータおよびパス名に対処する名前空間への対応物は、顧客のファイルを記憶するために使用される実際の記憶インフラストラクチャである。

ハイパーサーバの特性により、Ｈｙｐｅｒｆｉｌｅｒが構成されおよび拡張された場合、基数、およびクラスの一部であるハイパーサーバの記憶装置特性によって識別されることができる別個の記憶装置クラスを作成するハイパーサーバを構成することは、容易である。したがって、極端な手段として、最大限の保護のために、複製が３つまたはさらに４つのメンバーにわたって行われる高冗長性記憶装置クラスに属するハイパーサーバを有し、他の極端な手段として、複製を全く提供することができず、一時データおよび低い本質的価値を伴うデータのみに使用されるであろう無冗長性記憶装置クラスに属するハイパーサーバを有することが可能である。同様に、ＨＭにわたる冗長性を伴わず、弾力性を増加させるが高い可用性を実装しない、ある程度の内部冗長性を伴うハイパーサーバおよび記憶装置クラスを構成することが可能である。（基数が１に設定され（冗長性がない）、ハイパーボリュームがＲＡＩＤセットで作成されるハイパーサーバが、これを達成することができる。この場合、（構成に応じて）ＲＡＩＤセット内の１つ以上のドライブの損失に対する弾力性があるが、そのようなハイパーサーバをサポートする物理的または仮想デバイスのクラッシュ中の可用性の損失に対する保護を提供しない。）

記憶装置クラスはまた、使用中のドライブの種類にも基づき得る。例えば、顧客は、より良好に保護される必要があるデータにＳＡＳドライブを専念させるために、ＳＡＴＡおよびＳＡＳドライブの両方を使用するＨｙｐｅｒｆｉｌｅｒを有することを所望し得る。また、記憶装置クラスは、実際に、低頻度で使用されているデータの低コスト記憶装置のための外部オブジェクト記憶部と連動することができる。

新しいファイルが作成された場合、Ｈｙｐｅｒｆｉｌｅｒの名前空間は、ファイルが常駐するディレクトリ、ファイルの名前のサフィックス等に基づいて、記憶装置クラスをファイルに割り当てる構成規則を使用して、適切な記憶装置クラスを選択する。

Ｈｙｐｅｒｆｉｌｅｒは、メタデータを走査し、各ファイルが顧客選択時間窓内でアクセスされたかどうかを検証することによって、記憶装置クラスにわたってファイルを移動させることができる内蔵機構を有する。次いで、顧客選択ポリシーは、最近アクセスされていないファイルを、より低い可用性および／またはより高いアクセス時間を伴うより低い記憶装置クラスに移動させることができる。これは、自動的に行われ、そのようなファイルのパス名が全く影響を受けないであろうから、名前空間に影響を及ぼさず、走査は、名前空間のみに影響を及ぼすであろうから、いかなる実際のディスク入出力も伴わずに行われるであろう。

（名前空間抽象概念）
名前空間は、Ｈｙｐｅｒｆｉｌｅｒの中心である。名前空間の分散型性質は、メタデータおよびデータの両方が完全分散型であるため、Ｈｙｐｅｒｆｉｌｅｒの線形拡大縮小の手掛かりである。

名前空間の設計は、より従来的なファイルシステム設計の一部ではなく、現代のサーバのコンポーネントの相対的性能および能力により意味を成す、いくつかの重要な観察を中心に展開する。

現代のＮＩＣによって提供されるネットワーク帯域幅および待ち時間は、ローカルハードディスクの特性と良好に匹敵するか、それを超える。また、ハードディスクが維持することができる１秒当たりの入出力動作の最大数は、過去数年の間にほとんど変化しておらず、依然として１つのドライブ当たり約１００に限定される。

現在のマルチコアＣＰＵは、記憶および入出力動作のための計算能力を交換することを可能にする。

名前空間自体をデータ空間から完全に分断することができる。こうすることは、性能属性に関して、データ空間が記憶されるデバイスとは非常に異なり得るデバイス上に名前空間を配置することを可能にする。これは、データ記憶部へのアクセス時間にかかわらず、効率的な高速パス名参照を確実にするために重要であり得る。

コンピュータまたはＨＭで利用可能なＲＡＭの量は、通常、１ギガバイトを超える。これは、ファイルシステムメタデータを構造化する新しい方法を可能にする。

Ｈｙｐｅｒｆｉｌｅｒは、単一のハイパーサーバを伴って構成されることができることに留意されたい。この場合、全ての名前空間およびデータ空間は、唯一のハイパーサーバによって管理される。結果として生じる名前空間は、典型的には、ネットワークにわたってアクセスされるために利用可能である。しかしながら、アーキテクチャはまた、それがサポートする抽象概念がこれを可能にするため、ローカルファイルシステムを効率的に実装することができる。

しかしながら、Ｈｙｐｅｒｆｉｌｅｒは、概して、複数のハイパーサーバに及ぶことが期待される。これを達成するために、名前空間およびデータ空間の両方は、ハイパーサーバにわたって分配される。最初に、どのようにして名前がハイパーサーバにわたって分配され、次いで、どのようにして名前空間のローカル部分がハイパーサーバ内で対処されるかを議論する。

（ハイパーサーバにわたる名前空間の分配）
ハイパーサーバにわたる名前空間の分配は、任意のクライアントが、その要求を送信すべきハイパーサーバを即時に認識するように行われる。分配基準は、以下の考慮事項に依拠する。
・ディレクトリのコンテンツを効率的に一覧化する能力は、分散型名前空間内で保持されなければならず、性能は、集中型名前空間の性能に劣るべきではない。
・名前空間内で新しいコンポーネントを作成する能力は、名前の対立が存在するかどうかを検証する能力に依存し、これは、効率的にサポートされなければならない。
・ディレクトリ内のファイルの存在は、データファイル自体が、その親ディレクトリにサービス提供する同一のハイパーサーバによって管理されることを示唆すべきではない。これは、ボトルネックを回避するために重要であり、ファイルおよびディレクトリがハイパーサーバにわたって分配されることを可能にする。

ファイルシステムオブジェクト名は、ファイルシステムオブジェクトの親ディレクトリに基づいて、Ｈｙｐｅｒｆｉｌｅｒにわたって分配される。このスキームは、Ｋｏｓｈａで採用されるものに類似し、ディレクトリ名を異なるハイパーサーバにハッシュ化する。Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ＡＣＭ／ＩＥＥＥ ＳＣ２００４： Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｃｏｍｐｕｔｉｎｇ，Ｎｅｔｗｏｒｋｉｎｇ ａｎｄ Ｓｔｏｒａｇｅ Ｃｏｎｆｅｒｅｎｃｅ，Ｐｉｔｔｓｂｕｒｇｈ，ＰＡ，Ｎｏｖｅｍｂｅｒ ６−１２，２００４内のＡｌｉ Ｒａｚａ Ｂｕｔｔ，Ｔｒｏｙ Ａ．Ｊｏｈｎｓｏｎ，Ｙｉｌｉ Ｚｈｅｎｇ，ａｎｄ Ｙ．Ｃｈａｒｌｉｅ Ｈｕ，“Ｋｏｓｈａ： Ａ Ｐｅｅｒ−ｔｏ−Ｐｅｅｒ Ｅｎｈａｎｃｅｍｅｎｔ ｆｏｒ ｔｈｅ Ｎｅｔｗｏｒｋ Ｆｉｌｅ Ｓｙｓｔｅｍ”を参照されたい。しかしながら、Ｋｏｓｈａとの主要な違いは、ハッシングがサブツリーよりもむしろ任意の個々のディレクトリに適用されることである。したがって、ディレクトリとその子サブディレクトリとが異なるハイパーサーバによって管理されるであろう可能性が高い。ディレクトリは、名前空間内で直接表される。したがって、それらは、ファイルに使用されるデータ空間内に別個の記憶領域を必要としない。

パス名を参照することによって、クライアントは、パス名がファイルまたはディレクトリを指すかどうかを把握しない場合があることに留意されたい。いずれの場合においても、これは、パス名内のリーフコンポーネントの性質が何かを識別するために、親ディレクトリを利用するであろう。これがファイルである場合には、親ディレクトリを管理するハイパーサーバが、全ての問い合わせが送信されるべき場所である。リーフコンポーネントがディレクトリである場合には、その親は、そのディレクトリの全ての関連属性を記憶し、親のハイパーサーバは、要求の標的であるべきである。その上、ディレクトリのコンテンツを一覧化する要求は、ディレクトリを管理するハイパーサーバに送信される必要がある。本質的に、ディレクトリは、複数のハイパーサーバ内で複数のインカーネーション（ｉｎｃａｒｎａｔｉｏｎ）において存在する。

ディレクトリ情報は、その親を管理するハイパーサーバ内に記憶される。これは、ディレクトリのための権威あるハイパーサーバである。

ディレクトリ自体を管理するハイパーサーバは、ディレクトリのコンテンツのための権威あるハイパーサーバであり、そのディレクトリ内のあらゆるものに対する全ての要求は、このハイパーサーバに到達すべきである。

任意のディレクトリのシャドウコピーが、名前空間接続性を保証するために、必要に応じてハイパーサーバ内に存在することができる。

これを例示するために、「／ｆｉｒｓｔ／ｓｅｃｏｎｄ／ｔｈｉｒｄ」と名付けられたディレクトリの場合を考慮されたい。「／」（Ｈｙｐｅｒｆｉｌｅｒ全体のルーツ）が、ハイパーサーバＡにハッシュ化され、「ｆｉｒｓｔ」が、ハイパーサーバＢにハッシュ化され、「ｓｅｃｏｎｄ」が、ハイパーサーバＣにハッシュ化され、「ｔｈｉｒｄ」が、ハイパーサーバＤにハッシュ化されることを仮定されたい。ここで、「／ｆｉｒｓｔ／ｓｅｃｏｎｄ／ｔｈｉｒｄ」の属性を要求したい場合には、要求はＣに送信されるべきである。一方で、「／ｆｉｒｓｔ／ｓｅｃｏｎｄ／ｔｈｉｒｄ」のコンテンツを一覧化する、または「／ｆｉｒｓｔ／ｓｅｃｏｎｄ／ｔｈｉｒｄ」の下の任意のファイルにアクセスする要求は、ハイパーサーバＤを標的にすべきである。これに加えて、「／ｆｉｒｓｔ／ｓｅｃｏｎｄ／ｔｈｉｒｄ／ｆｏｕｒｔｈ／ｆｉｆｔｈ」と名付けられたディレクトリが存在する場合、「／ｆｉｒｓｔ／ｓｅｃｏｎｄ／ｔｈｉｒｄ／ｆｏｕｒｔｈ／ｆｉｆｔｈ」を伴う要求を処理することができなければならない任意のハイパーサーバはまた、「／ｆｉｒｓｔ／ｓｅｃｏｎｄ／ｔｈｉｒｄ／ｆｏｕｒｔｈ」のシャドウコピーも含まなければならない。

（名前空間の持続性）
仮想メモリベースの名前空間は、明確に持続的であることを要求し、これは、仮想メモリ内のファイルメタデータに行われる任意の修正がクラッシュ後でさえも利用可能であるように、そのコンテンツが実際にディスクにバックアップされなければならないことを意味する。これは確かに、システム性能への影響を最小化しながら、これを提供するためにインテントログ設備を利用するＨｙｐｅｒｆｉｌｅｒの場合である。インテントログはトランザクショナルであり、名前空間が最後に完了された名前空間トランザクションに対して常に最新の状態であることを可能にすることに留意されたい。クラッシュの場合、ハイパーサーバの再起動は、ディスク上の名前空間の持続的コピーに記録された最後のトランザクションを適用すること、および最新の完了したトランザクションへのそのメモリ内見解の初期化を伴う。

Ｈｙｐｅｒｆｉｌｅｒ内の名前空間は、そのデータをデータリポジトリ内に記憶する必要性がないため、データリポジトリから分断される（参考文献［２］）。この分断は、これらの実施形態におけるファイルシステムの設計を単純化し、名前空間内のデータの量を最小化する。したがって、これは、それをＲＡＭに記憶するために、後者を好適にする。

（主要データ構造）
Ｈｙｐｅｒｆｉｌｅｒの名前空間内のパス名の集合は、パトリシア木として、すなわち、一種の順序付けられたツリーデータ構造として実装される。具体的には、このツリー様データ構造は、いくつかの非常に重要な属性を有する。
・これは、ツリーのサイズに依存しないが、むしろ参照されている文字列（Ｈｙｐｅｒｆｉｌｅｒ内のパス名）のサイズに依存する、極めて高速の検索を達成する。
・これは、共通ステムを伴うアイテムをともにグループ化するという点で、極めてコンパクトである。
・これは、分別された順番でそのエントリを保つ。

最悪の場合、任意の個々のパトリシア木ノードは、２５６以下の子を有し、これは、ツリー構造がリンクされたリストに類似するものに畳み込まれることを防止する自動機構を提供する。これは、主要な肯定的性能影響を有する。

Ｈｙｐｅｒｆｉｌｅｒパトリシア木は、ノードの性質についての基本情報を保つ固定サイズノードで作成され、ノードの性質は、ノードの種類（ファイルシステムファイルまたはディレクトリ等のファイルシステムノードよりもむしろ、パトリシア木を組み立てるために必要とされる内部ノードであるかどうか）、それに関連付けられる文字列、ノードおよびその子に作用するために必要とされるロック、子および親ノードへのポインタ等を含む。

ファイルシステム内の各ノードが、（許可、所有権情報、日付、および範囲ＩＤのような）ファイル属性とともに、任意の長さの文字列を記憶することができなければならない場合、それは、多くのノードがフィールドのうちのいくつかを使用しないであろう大型データ構造である必要があろう。例えば、内部パトリシア木ノードは、ファイル属性を必要としない。ディレクトリノードは、それらに関連付けられる情報の全てが、データリポジトリ等の中よりもむしろパトリシア木の内側にあるため、範囲ＩＤを必要としない。

これを最良に克服するために、各ハイパーサーバ上のローカル名前空間は、固定サイズのエントリの３つの連続したアレイに関して実装される。
・ファイルテーブル（ＦＴ）−このアレイは、各ファイルの第１の範囲に対する範囲ＩＤとともに、ファイルまたはディレクトリの属性を記憶する。参考文献［２］で説明されるように、このＩＤは、その名前空間コンポーネントが常駐する同じハイパーサーバ内にデータが常駐する必要がないように、Ｈｙｐｅｒｆｉｌｅｒ全体にわたって大域的である。
・文字列テーブル（ＳＴ）−このアレイは、連続した塊に集約されることができ、ノードテーブル内に収まらないであろう文字列を記憶する固定長セルで作成される。
・ノードテーブル（ＮＴ）−このデータ構造は、必要とされる場合、文字列のサイズがＮＴエントリで利用可能な記憶容量を超えるときのＳＴ内の文字列または文字列のＩＤ、パトリシア木内の接続ＮＴエントリのインデックス、ＮＴエントリに関連付けられたフラグ、および関連ＦＴエントリのインデックスとともに、各ノードのロックを記憶する。

ＮＴの２つのエントリは特別である。
・エントリ０は、利用可能な名前空間の全てのルートへのポインタの役割を果たす。この間接レベルを有することは、将来、１つの名前空間または複数の名前空間のスナップショットを実装することを可能にし得る。
・ＮＴのエントリ１は、ＰＯＳＩＸ名前空間のルートディレクトリであり、「／」に対応する。

任意のＮＴエントリは、以下に関連付けられることができる。
・関連文字列がエントリ内に収まり、エントリが関連ＦＴエントリを有さない場合（内部パトリシア木ノード、またはパス名の中間コンポーネントにすぎないディレクトリの場合で、どちらかが短い関連文字列を有する限り）、他のテーブル内のエントリに関連しない。
・これが短い文字列を伴うファイルまたはディレクトリである場合、ＦＴ内の１つのエントリ。
・これが、内部パトリシア木ノード、またはパス名の中間コンポーネントにすぎないディレクトリであり、文字列がノードの容量を超える容量を有する場合、ＳＴ内の１つ以上の連続したエントリ。
・これがそのＮＴエントリの容量を超える文字列を伴うファイルまたはディレクトリである場合、１つのＦＴエントリおよび１つ以上の連続したＳＴエントリ。

各ＨＭ内の名前空間サーバが、（存在する場合）関連データリポジトリも作動させるマルチスレッドプロセスを実行することに留意されたい。スレッド間の同期化が、名前空間にアクセスする際に必要とされ、排他的アクセスが、更新されているノードに限定される一方で、修正されていないパトリシア木ノードへの共有アクセスを可能にするであろうため、これに読み取り書き込みロックを利用することが望ましい。しかしながら、ここでの最重要点は、ＦＴ、ＳＴ、およびＮＴのためのコンパクトなデータ構造を有することである。各ロックが多くのバイト数を必要とされる場合、ＮＴのサイズは大幅に増大し、これはＲＡＭの中でそれを保つ可能性を制限するであろう。したがって、Ｈｙｐｅｒｆｉｌｅｒで使用されるスレッディング設備は、わずかなメモリ占有容量を有する読み取り書き込みロックを実装する。

また、パトリシア木を横断する際のロッキングアルゴリズムは、読み取り型動作については、各ノードが読み取りモードにロックされ、その子のそれが取得されたときにその親がロック解除されるようなものである。これは、ロックすることを２つのレベルに限定し、階層が降下させられるにつれて、パトリシア木内の上部ノードが利用可能になるように、階層様式でそれを行う。これは、読み取り側と書き込み側との間の競合を最小化し、デッドロック（循環性）の４つの必要条件のうちの１つを排除する、ロックの間の順序付けを誘発するため、デッドロックを回避する。

書き込み型動作については、修正されるノードの親に到達するときに、書き込みモードにロックされ、名前空間修正が完了するまでロックされたままであるという事実を除いて、類似アルゴリズムが適用される。

また、パトリシア木ノードをロックすることによって、他のスレッドとの起こり得る対立を伴うことなく、ＮＴエントリ（存在する場合）に関連付けられるＦＴおよびＳＴエントリに作用できることにも留意されたい。

自由リスト上の競合を回避するように、名前空間の一部であるテーブルの各々の中のエントリを割り付けおよび割り付け解除するために、別個のミューテックスが使用される。

（持続性およびインテントログ）
持続性は、ファイルシステムにおいて最重要であり、名前空間パトリシア木は、持続的でなければならない。それを完全にＲＡＭベースにすることは、これを達成しない。この理由により、前述のテーブルの各々は、バッキングストアとしてファイルを有し、任意の変更がバッキングストアに書き込まれ、再起動時にテーブルのコンテンツがバッキングストアから読み取られる。

名前空間では、ＮＴ、ＦＴ、およびＳＴ内の各エントリは、巡回冗長検査（ＣＲＣ）コードを含む。これは、エントリが修正される度に計算される。これらのコードは、エントリがディスクから読み返されるときにチェックされ、ビット崩壊から、および、Ｈｙｐｅｒｆｉｌｅｒが動作するように意図されている規模で無視できない、稀ではあるが起こり得る未検出ディスク読み取りエラーから、主要名前空間データ構造を保護する。

テーブルエントリの各々の小さいサイズを考慮すると、書き込み動作は、バッキングファイル内で多くのランダム検索を必要とし、したがって、ドライブが実現することができる利用可能な入出力動作のうちのいくつかを取り得るので、非常に高価であり得る。

この理由により、全ての更新は、インテントログを使用することによって行われる。後者は、メモリの固定サイズ領域（これは現在１メガバイトに設定されている）をメモリマップすることによって実装される。バッキングストアへの一セットの更新が必要とされるときはいつでも、それらは、各々が関連するテーブルの指示とともにインテントログにコピーされる。単一の動作のための更新が、一緒に結び付けられる。更新を行うスレッド（ハイパーサーバ一次メンバー）は、結び付けられた変更をインテントログに非同期的にプッシュ配信し、次いで、更新を二次メンバーにプッシュ配信する。同期挙動が要求される場合、スレッドは、二次更新が完了されることを待ち、次いで、インテントログが終了されることを待つ。一方で、非同期更新がＯＫである場合、スレッドは、これまで保持された書き込みロックを解放することによって動作を完了する前に、二次更新が受信されることを待つ必要しかない。

実際のバッキングファイル内の最終ランダムオフセットを標的にすることが、代わりにいかなる中間検索も必要とし得ないにもかかわらず、インテントログは、連続したファイル、したがって、更新のリストにマップされることが期待される。新しい更新が、最初に空のインテントファイルに追加されるので、各マップされたページが満杯になると、非同期的に消去され、更新を持続的にする。同期入出力が要求されるか、または呼び出し側が‘ｆｓｙｎｃ（）’呼び出しを行う場合、クライアントへの確認は、目的とするインテントログの部分がディスクにコミットされる場合のみ起こる。したがって、更新は、確認が返信される時間まで安定して記憶されている。インテントログの終了に達するとすぐに、新しいものが着信更新のために作成される一方で、サービススレッドが、非同期的にインテントログから更新を抽出し、それらを実際のバッキングファイルにコミットし始める。これが終了したとき、インテントログは破棄される。クラッシュが起こった場合、再起動時に、名前空間の初期化は、更新がバッキングファイルに伝搬されるように、依然として存在している全てのインテントログの処理を伴う。全ての未解決インテントログが処理されて削除され、バッキングストアが更新されたときのみ、それらは、メモリ内で名前空間データ構造を構成する３つのアレイ（ＦＴ、ＳＴ、およびＮＴ）に読み込まれる。

（バッキングストアおよびインテントログのさらなる観察）
第１のリリースの標的である上記のスキームの代替案が、この副次節で説明される。

この時点で、完全にデータ投入された名前空間を有するために、ハイパーサーバメンバーが再起動されるときのみ、バッキングストア（ＮＴ、ＳＴ、およびＦＴのコンテンツを複製する３つのファイル）が使用されることが明確なはずである。

インテントログからバッキングストアを更新することは、個々のテーブルエントリを更新するための、一連の検索をディスク上で発生させる。これは、直接クライアント要求に対処するためにディスクが実行することができる入出力動作の数を削減するので、望ましくない。したがって、バッキングストアを更新する良好な方式は、インテントログからファイルへの更新を、行われているディスク入出力動作の数が所与の閾値を下回る期間まで遅延させるものであり得る。明確に、この数が潜在的に無限に増大し、合理的であるものを超えるディスクスペースを使用し得るので、多すぎないインテントログが保たれることを保証する必要がある。したがって、非常に長期間にわたって更新を遅延させることを回避するために、ある形態のバックプレッシャが存在しなければならない。

一方で、インテントログの何らかの統合を行うことも可能である。更新されたテーブルエントリのビットマップを保つことができる。これらのビットマップは、最初に０に設定されることができる。次いで、インテントログを後方へ走査し、更新されるべきビットマップに対して更新ビットを設定することができる。エントリ更新が走査されているログの中で見出されたとき、エントリに対する更新ビットがすでに設定されている場合、データの後続のバージョンですでに更新されているので、エントリはさらなる更新を必要としない。したがって、その更新エントリを統合ログからパージすることができる。プロセスは、より古いインテントログが処理されるまで継続するであろう。このスキームは、古くなったエントリがないものへの複数のインテントログの周期的な畳み込みを可能にするであろう。

最終的に、個々のバッキングストアファイルを完全に排除することも可能である。実際、ＲＡＭテーブルがディスクから読み取られる必要があるのは再起動時のみであるため、これは、インテントログからそれらを直接読み取ることによって行うことができ、そうでなければ更新トラフィックの存在下で増大し続けるであろう、それらに使用される記憶の量を制限するために、ログの周期的統合を行うことができるという結論に単純に達することができる。

ところで、単一のログファイルが使用されるが、周期的に、それの後続のセクションが、新しい更新を追加するようにメモリマップされるようなインテントログのためのわずかに異なるアプローチを想像することも可能である。これは、インテントログのコンテンツを削減するであろう。大きいファイルは、古くなった更新を取り除くために、以前に議論されたものに類似するスキームを用いた統合を受けることができる。

これは、将来のＨｙｐｅｒｆｉｌｅｒリリースにおける実際の必要性に基づいて、名前空間の持続性を管理するための初期スキームを進展させることができる、一連のトリックである。

（二次ハイパーサーバメンバーの更新）
一次および二次ＨＭは、概して、独立して作用し、異なる読み取り型要求を処理する。しかしながら、ローカル変更を行う書き込み型要求は、一次メンバーによって、調整され、成功した場合、要求クライアントに返信する前に、二次メンバーの状態が一次メンバーと一致していることを確認する。

ハイパーサーバメンバーの間の処理および各メンバー内で作動する多数のスレッドの非同期挙動により、一次メンバーが、それが受信する書き込み型要求をその二次メンバーに送信した場合、それらは異なって取り扱われ、機能的に同等であろう結果をもたらす可能性が高いが、異なるメンバーに、種々の名前空間テーブルに対する異なるエントリを使用させるであろう。

これは、それだけでは壊滅的ではないだろうが、メンバーにわたる一貫性の検証および修復をより複雑にするであろう。これはまた、別の結果も有する。名前空間がデータリポジトリ内で指し示すファイルは、それらの名前空間コンポーネントを指し示し返す必要がある。これは、さらなる一貫性チェックが名前空間とデータ空間との間で行われ、ガーベジコレクションが孤立データファイルを訂正するために利用可能になることを可能にする。（データ側ハイパーサーバのメンバーのうちの任意のメンバー上の）所与のファイルが、常に、名前空間ハイパーサーバ上の任意のメンバー上の同じＮＴエントリに接続されていることを名前空間が保証する場合、データファイルは、ＮＴエントリのインデックスを単純に記憶することができる。そうでなければ、データファイルは、名前空間ハイパーサーバのメンバーの各々に対するＮＴエントリの各々のインデックスを記憶すべきであるか、またはコンポーネントに対する可変長パス名を記憶すべきである（それは、但し、パス名に影響を及ぼす名前変更が起こる度に変更される必要があるであろう）。

上記の複雑な事態を回避するために、Ｈｙｐｅｒｆｉｌｅｒの名前空間は、名前空間ハイパーサーバメンバーのうちの任意のメンバーにおける所与のファイルシステムオブジェクトに対して使用されるべき、名前空間における同じテーブルエントリを有することに依拠する。しかしながら、これは、クライアント要求の非同期実行にもかかわらず、割り付けられるテーブルエントリが同一である必要があるので、二次メンバーでの要求の実行が対処されるべき方法に対する変更を要求する。これは、そのような二次動作を効率化する機会でもある。なぜなら、一次メンバーの状態を反映するようにテーブルエントリを変更するために必要な方法が、二次メンバーに伝えられる必要があるからである。

留意すべき重要な１つの点は、一次メンバーからの書き込み更新が適用された場合、継続中の読み取り型要求が自由にフローすることができなければならないことである。これが成功するために、一次メンバーは、更新を行うために排他的モードにロックされなければならないＮＴエントリの指示を送信しなければならない。これは、任意の着信読み取り型要求が、過渡状態にあるデータ構造へのアクセスを得ることを防止するであろう。その他の点に関し、一次メンバーは、生成され、そのローカルインテントログにコミットされる更新リストを各二次メンバーに送信することのみ必要である。なぜなら、このリストが、一次メンバー上で行われたものを複製する正確なレシピであるからである。

わずかに複雑な事態がもう１つある。更新さえも一次メンバー上の同時スレッドによって行われるので、そのような更新が二次メンバー上で同一の順序で行われることが望ましい。この理由により、一次および二次メンバーの両方は、シーケンサ、すなわち、動作が行われる順番を記録するモジュールを実行する。これは、一次および二次メンバー上で、異なる方法で使用されて動作する。

一次メンバーにおいて、各更新の開始時に、排他的ＮＴエントリロックが取得された後、更新スレッドは、シーケンスＩＤを要求して保存する。これは、（ラップアラウンドで）シーケンサが単調に生成する６４ビット数である。唯一の排除された値は、０である。一次メンバーは、更新リストとともにそれを二次メンバーに送信するために、この数を取得してそれを保存する。

二次メンバーにおいて、更新要求を受信するスレッドは、シーケンサのそのローカルコピーに、そのシーケンスＩＤを承認するよう求める。前のシーケンスＩＤがすでに処理されている場合、シーケンサは、スレッドが続行することを可能にする。そうでなければ、スレッドは、前のシーケンスＩＤが完全に処理されるまで待つ。スレッドは、そのシーケンスＩＤを処理するための承認を受信した後、目的とするＮＴエントリのための排他的ロックを取得し、適正な順序で全てのテーブルエントリを更新し続ける。全てが更新されるとき、スレッドは、それがそのシーケンスＩＤを用いて行われることをシーケンサに伝え、これは、次の更新が続行することを可能にするであろう。（ＩＤを取得した動作が中断されなければならなかった場合、スレッドがシーケンスＩＤを破棄することを可能にする設備が利用可能である。）

二次メンバーと対比した一次メンバーにおける更新の実行での１つの重要な側面は、全ての割り付け選択が一次メンバーで行われ、一次メンバーは、一次メンバーが維持する自由リストから、各テーブル内で利用可能な次のエントリを取り出すことによって、一次メンバーがこれを行うという事実に関係する。自由リストは、使用されていない各テーブルのエントリを一緒に結び付ける。一方で、二次メンバーは、使用するもののインデックスが、各二次メンバーが受信する更新リストの中にあるので、二次メンバーは、割り付けるべきテーブルエントリを選択する必要がない。したがって、二次メンバーは、各自の自由リストを維持する必要がない。

名前空間の状態に対する更新に対処する際のハイパーサーバメンバーの非同期動作を要約する。所与のハイパーサーバのメンバーは、ハイパーサーバのメンバーの間で、名前空間のサブコンポーネント、すなわち、ファイルテーブル（ＦＴ）エントリ、文字列テーブル（ＳＴ）エントリ、およびノードテーブル（ＮＴ）エントリが、同一の識別子を用いて、同一の動作のために割り付けられるか、または削除されるように構成される。たとえサブコンポーネントが同一の識別子を用いて使用されたとしても、ハイパーサーバのメンバーは、更新要求（つまり、名前空間の状態の更新を引き起こす任意の要求）に対処する際に、非同期的に作動するように構成される。メンバーの非同期動作を可能にするために、更新要求は、一次メンバーによって連続番号を割り当てられ、これらの連続番号は、更新が二次メンバーによって行われる様式における順番を提供するために使用される。削除、作成、または修正されるエンティティ（ファイルまたはディレクトリあるいはシンボリックリンク）の親であるファイルシステムノードを使用して、一次メンバーによって、書き込みロックが適用される。次いで、一次メンバーは、ローカル更新を行う。次いで、これは、連続番号、取得されるべきロックのリスト、および更新されるべき名前空間エントリの新しいコンテンツを含むパケットを組み立て、次いで、パケットを二次メンバーの各々に送信する。パケットを受信すると、各二次メンバーは、連続番号が最新になることを待ち、次いで、パケットで特定される書き込みロックを、ファイルシステムノードのその対応するコンポーネントに適用し、次いで、ローカル更新を行う。最終的に、二次メンバーは、確認を一次メンバーに与える。この時点で、二次メンバーは、他の同時更新を行うことができるように、次の連続番号へ前進することができる。更新が、上書きが後に続く削除を含む場合において、削除が冗長であるので、次いで、一次メンバーは、上書きのみを伝送する。

二次メンバーのそれぞれから確認を受信すると、一次メンバーは、書き込みロックを除去し、その時点で、一次メンバーは、以下のプロトコルのうちの１つに従って、要求クライアントに返信する。（１）更新が行われ、安定して記憶されているときに、二次メンバーが一次メンバーに確認する、または（２）更新が行われたときであるが、更新が安定して記憶されるまで待つことなく、二次メンバーが一次メンバーに確認する、または（３）一次要求を受信したときであるが、二次メンバーが実際に更新を実行する前に、二次メンバーが一次メンバーに確認する。これらのプロトコルのうちの所与の１つを使用するかどうかの決定は、性能と信頼性との間の所望のトレードオフに従って行われる。

いくつかの重要な考慮事項が、上記から生じる。
・アクティブな一次メンバーのみが、その自由リストを使用して更新する必要があるメンバーであるため、自由リストは、一次メンバーを作動させるために関連するのみである。
・テーブルの間に階級があり、その中で、ＮＴが主要な役割を有し、ＦＴおよびＳＴは、補助的な役割を果たす。換言すると、ＦＴおよびＳＴ内のエントリは、１つのＮＴエントリによって参照されない限り、割り付けられることができない。
・ＮＴ内のエントリは、別のエントリによって、ＮＴ内で参照される場合のみ使用されている。
・テーブルは、各テーブルがＲＡＭから処理されるとき、または再起動後にそのバッキングストアから読み取ることによって処理されるとき、自由リストが再作成されることができるような方法で設定される。

これは、２つの主要な結果を有する。
・自由リストが持続的であり、各テーブルに対してファイル記憶部上で裏付けられていることを確認する必要がない。なぜなら、自由リストは、必要とされるとき（すなわち、ハイパーサーバが再起動し、一次メンバーが動作可能にならなければならないときに、二次メンバーが故障した一次メンバーに取って代わるとき）、再構築することができるからである。
・その自由またはビジー状態は、他のテーブルエントリから再構築されることができるので、（テーブルのうちのいずれかの中の）テーブルエントリを自由にする任意の動作は、バッキングストアに到達する必要がない。

上記の実用的意義は、以下の通りである。
・テーブルエントリのうちのいずれかを伴う、自由動作のうちのいずれも、二次メンバーに到達する必要がない。
・テーブルエントリのうちのいずれかを伴う、自由動作のうちのいずれも、インテントログおよびバッキングストアに到達する必要がない。

これは、名前空間のためのハイパーサーバ更新の論理を単純化し、インテントログおよびバッキングストアへの入出力トラフィックを削減するという点で、非常に有用である。

いずれの場合にしても、任意の二次メンバーが、一次メンバーが要求した更新を実行すると、それは最初に、更新をそのインテントログおよびバッキングストアに送信し、次いで、動作の開始時にそれが取得したＮＴエントリロックを放棄し、最終的に、それが使用していたシーケンスＩＤが完全に処理されたことをシーケンサに知らせなければならない。

（ハイパーサーバメンバー再起動）
以前に概説されたように、一次メンバーは、（クラッシュすることによって、または退去させられることによってのいずれかで）それらが属するハイパーサーバから退出することによって、それらの役割を変更することしかできない一方で、二次メンバーは、一次メンバーがもはや存続しなくなるときに一次メンバーになることができる。

若干類似する状況は、システムシャットダウンおよび後続の起動の結果としてハイパーサーバが再起動される場合である。

２つの事例は、その役割を持たなかったメンバーが一次メンバーにならなければならないという点で類似する。２つの事例の間の違いは、二次から一次への遷移が、メンバーがすでに起動して作動していたことを示唆する一方で、再起動がハイパーサーバメンバー環境全体の設定を要求することである。

二次から一次への遷移の場合、二次メンバーは、すでに起動して作動している。これは、読み取り型要求を処理し続ける必要しかなく、その二次メンバー上の書き込み型動作を調整することが可能でなければならない。これを行うために、名前空間に関し、全てのテーブルが一貫した状態であること、および、これが、必要に応じて新しいテーブルエントリを割り付けるための利用可能な自由リストを有することを確認する必要がある。

上記を達成するために、新たに選択された一次メンバーは、以下を行う。
・これは、ＮＴ、ＦＴ、およびＳＴエントリの各々の中の‘ｒｅｆｅｒｅｎｃｅｄ’ビットをリセットする。
・これは、ルート名前空間ノードで始まるＮＴを走査し、ノードツリーを横断する際に遭遇する任意のエントリに対して‘ｒｅｆｅｒｅｎｃｅｄ’ビットを設定する。
・前のステップの終わりに、これは、ＮＴ全体を再度走査する。これは、‘ｒｅｆｅｒｅｎｃｅｄ’ビットが設定されていない全てのエントリを解放し、それらをＮＴ自由リストに追加する。‘ｒｅｆｅｒｅｎｃｅｄ’ビットが設定された全てのＮＴエントリについて、ＦＴエントリおよび／またはＳＴエントリへの参照を有するかどうかを確認するようにチェックし、これらのエントリに対する‘ｒｅｆｅｒｅｎｃｅｄ’ビットを設定する。
・次いで、これは、ＦＴおよびＳＴテーブルを走査し、それらの‘ｒｅｆｅｒｅｎｃｅｄ’ビットが設定されていない全てのエントリを解放して適切な自由リストに追加する。

上記の終わりに、テーブルおよび自由リストの完全性は、完全に再構築され、新しい一次メンバーは、完全に動作することができる。

ハイパーサーバが再起動される場合において、一次メンバーは、上記を行う必要がある。しかしながら、その前に、ハイパーサーバメンバーの各々は、（存在する場合）インテントログファイルを読み取り、更新をバッキングストアに適用し、処理されたインテントログを削除しなければならない。これが行われると、各メンバーは、ファイルの各々を適切なテーブルに読み込み、初期化を完了すべきであり、一次メンバーのみが自由リストを再構築しなければならない。

（新しいメンバーの初期化）
メンバーがハイパーサーバから退去させられるか、またはクラッシュする場合において、新しいメンバー（利用可能である場合）が、退出したメンバーに取って代わる必要がある。

典型的には、そのようなメンバーは、名前空間のそのコピーを再作成するために必要とする情報のうちのいずれも有さない。したがって、一次メンバーは、以下を行うことによって、新しいメンバーの初期化を引き継ぐ。
・これは、新しいメンバーが、最初は任意のクライアント動作を行うことを可能にされないような状態に新しいメンバーを設定し、クライアントにエクスポートされるハイパーサーバの状態がこれを反映する。
・これは、現在の位置を名前空間テーブルの各々の始まりに設定する。
・これは、テーブルの各々を走査し始め、使用中の各エントリのコンテンツを新しい二次メンバーに伝搬する。

これが進展するにつれて、一次メンバーは、エントリテーブルがテーブルの各々のために処理されているというその概念を更新する。

着信クライアント要求が到着すると、新しい二次メンバーは、アドレス指定されないか、または、それらを一次メンバーに転送することによって、それに到達し得るものを破棄するであろう。一次メンバーが行う全ての更新は、二次メンバーにすでにコピーされた各テーブル内のエントリに影響を及ぼす更新、またはコピーされているエントリを超えるエントリに影響を及ぼす更新に分解され得る。現在のエントリに先行するものは、コピーが行われた時間以降、コピーされたエントリの状態が変化しているため、二次メンバーへの更新を生成する必要がある。現在のエントリに続くものは、これらのエントリが到達されると更新が適用されるであろうため、無視されることができる。

全てのエントリテーブルが処理されたとき、一次メンバーは、ハイパーサーバの状態を変更し、新しい二次メンバーを動作可能としてマークすることができる。

これの終わりに、新しい二次メンバーは、名前空間要求を処理することができる。これがデータリポジトリを有する場合、ファイルに対する要求に応答するその能力は、データリポジトリサブシステムの状態に依存し、そのコンポーネントによって対処される必要がある。

（名前空間の他の用途）
名前空間の構造は、一般的であり、パス名のＰＯＳＩＸビューに制約されない。具体的には、エントリ０が全ての名前空間のルートノードであるので、ＰＯＳＩＸ名前空間のルートを指し示すことに加えて、それは、他の子を有することもできる。

これは、ある種類の分散型代替名前空間を実装したい場合に役立つ。多くの可能性のうちの２つは、以下の通りである。
・範囲フィンガープリントを収集する代替名前空間。これらは、ハイパーサーバにわたって分散され、それらをハッシュ化することは、各エントリを管理するハイパーサーバのＨＩＤをもたらすであろう。これは、システムの第１のリリースの標的にされないが、範囲複製を実装するために使用されることができる。
・別の代替名前空間は、Ｈｙｐｅｒｆｉｌｅｒシステム自体によって使用される分散型ディクショナリとして使用されることができる。

Ｈｙｐｅｒｆｉｌｅｒ上にＡｍａｚｏｎ Ｓ３型オブジェクトストアを実装するために名前空間を使用することができるが、ファイルの第１の範囲ＩＤ（以下参照）をオブジェクトＩＤとして使用することができるため、特別な名前空間を使用する必要がないであろうことに留意されたい。範囲ＩＤは、それが記憶されているハイパーサーバをすでに識別し、したがって、追加の間接指定を必要としない。

（データ空間）
データ空間は、データリポジトリサブシステムを介して実装される。これは、一意のＨｙｐｅｒｆｉｌｅｒ全体に及ぶ範囲ＩＤ（ＥＩＤ）を通して識別される、ファイルデータのためのコンテナを集約し、ＥＩＤは、各そのようなコンテナが常駐するハイパーボリュームに関連する。したがって、名前空間内のデータコンテナへの参照は、１つのそのような一意のＩＤであり、名前空間コンポーネントが配置される同一のハイパーサーバ上でホストされる必要がない。

ハイパーボリュームのデータ空間コンポーネントは、ファイルデータが記憶されるリポジトリである。これは、４キロバイトの論理ブロックを管理する、範囲ベースのファイルシステムである。（理論上、１キロバイト論理ブロックは、１ファイルにつき無駄になる平均記憶容量が、１ファイルにつき５１２バイトであり、非常に多数の小さいファイルが存在するときはいつでも、相当量の記憶容量を節約することができるという利点を提供することができる。一方で、４キロバイトブロックは、平均無駄を１ファイルにつき２キロバイトまで押し進め、無駄な空間を４倍増加させるであろう。しかしながら、より新しいディスクドライブは、従来の５１２バイトの代わりに、４キロバイトディスクセクタを使用するため、４キロバイトを選択することは、両方の技術と適合性があり、より大きいファイルに及ぶために必要とされるブロックポインタの数も削減する。）

したがって、空ではないファイルのためのディスク上の最小サイズは、４キロバイトになる。これは、ファイルメタデータが名前空間内で完全に保たれるため、純粋のデータブロックリポジトリである。

一意のＥＩＤは、データ空間内の任意の範囲を識別し、データ空間を管理するハイパーサーバ内から、ならびに任意のクライアントあるいは他のハイパーサーバから、範囲のアドレス指定を可能にする。ＥＩＤは、以下のフィールドを含む８バイト構造であり、その含んでいるハイパーボリュームからの不透明スカラーとして取り扱われる。

範囲が割り付けられたハイパーボリュームのＨＩＤ。これは、Ｈｙｐｅｒｆｉｌｅｒ全体内で範囲を大域的に一意的、かつアドレス可能にする。

含んでいるハイパーボリューム内の範囲に対する開始ブロックの論理ブロックオフセット。これは、ハイパーボリューム内の開始ブロックの論理ブロックインデックスを直接識別する。

範囲が及ぶ論理ブロックの総数。これは、範囲内で読み取るためにどれだけのメモリがキャッシュ内で利用可能されなければならないかを、キャッシュマネージャに知らせる。

単一の範囲は、最大で４メガバイトに及ぶ。範囲がアクセスされるとき、それは、その全体で読み取られる。これは、単一のディスク入出力動作で、４メガバイト以下の任意のファイルを読み取ることができることを意味する。これは、入出力サブシステムの効率の主要な上昇である。順次アクセスが検出されるときに、読み取り要求が受信される前に、以下の範囲を読み込むことができるように、ＬＲＵアルゴリズムが、空間が取り戻されることを要求し、キャッシュがプリフェッチングを実装するまで、範囲がキャッシュ内にとどまる。（これは、Ｈｙｐｅｒｆｉｌｅｒにおいて普及アクセスモードとなるべきである。）

複数の範囲に及ぶファイルについて、第１の範囲は、高速検索を順方向に行うことが可能であるように、全てのファイル範囲のマップも記憶する。初期範囲が範囲キャッシュからパージされる必要があるとき、ファイルが依然としてアクセスされている場合、範囲マップに使用される領域は、ファイルが閉じられる時間までメモリ内で保持される。範囲マップ自体は、典型的なＵｎｉｘ（登録商標）ファイルシステムｉ−ノード内のブロックポインタのマップのように組織化される。これは、最初のいくつかの範囲が直接指し示される一方で、後続の範囲が、極めて大きいファイルに対する二重間接指定、次いで、三重間接指定を引き起こし得る、不平衡ツリー様構造である。

各ファイル範囲はまた、範囲が書き込まれるときに計算される範囲に対する２０バイトＳＨＡ−１フィンガープリントも含む。個々の範囲フィンガープリントは、範囲の完全性の検証を可能にする。ファイルの第１のセグメントはまた、個々の範囲の全てのフィンガープリントのうちの１つのフィンガープリントも計算する。この全体的フィンガープリントは、ファイル長とともに、最終的に、ファイルインスタンスに対する一意のＩＤを提供することができる。これは、２つの方法で使用され、すなわち、ファイル全体の完全性を検証し、システムの将来のリリースにおいてファイルレベル複製を実装するであろう。

範囲への書き込みは、ファイルのタイプがこれを無意味にしない限り、最初に範囲のコンテンツを圧縮した後に行われる。構成設備は、事実上非圧縮性のファイルがＣＰＵサイクルを無駄にすることを防止するためのこの決定において役立つ。同様に、ファイルシステムから読み込まれるデータは、使用される前に展開される。消費者は、この挙動がＣＰＵサイクルのためのデータ空間を交換することを可能にすることができる。それをサポートするデータ空間およびデータリポジトリについてのさらなる詳細が参照される。

（クライアント要求の管理）
クライアントがＨｙｐｅｒｆｉｌｅｒにおいて利用可能なルートディレクトリ（または任意の他のディレクトリ）をマウントすると、要求クライアントに与えられるアクセス保護特権に従って、マウントされたディレクトリの下でＨｙｐｅｒｆｉｌｅｒが利用可能にする任意のファイルおよびディレクトリにアクセスすることが可能にされる。

クライアントとＨｙｐｅｒｆｉｌｅｒとの間の典型的な相互作用は、以下の様式で起こる。本実施例は、オープン、読み取り、書き込み、およびクローズ呼び出しが、どのように挙動するであろうかを示す。

クライアントは、Ｈｙｐｅｒｆｉｌｅｒのマウントポイントの下でファイルを開く必要があるとき、クライアントは、マウント時に受信したＤＨＴを介して、ファイル名をローカルでハッシュ化して、その名前に責任があるハイパーサーバのＨＩＤを取り出す。

次いで、クライアントは、Ｈｙｐｅｒｆｉｌｅｒネットワーク層に、前のステップで取り出されたＨＩＤの名前空間ハイパーサーバへオープン要求を送信するよう求める。

クライアント上のＨｙｐｅｒｆｉｌｅｒネットワーク層は、ＨＩＤを標的名前空間ハイパーサーバ内のＨＭのアドレスにマップする。この時点で、ネットワーク層は、要求が、ファイルから読み取るため、またはファイルに書き込むためのオープンであるかどうかに応じて、異なって挙動する。読み取るためのオープンの場合、標的名前空間ハイパーサーバ内の任意のＨＭが、要求に対処することができる。したがって、クライアントは、（要求を分配するために）無作為に１つのＨＭを選択し、ＨＭに要求を送信する。書き込むためのオープンの場合、名前空間ハイパーサーバの一次ＨＭが、要求に対処すべきである。したがって、クライアントは、要求をそれに送信する。

成功した場合、名前空間ハイパーサーバのＨＭは、ファイルを記憶するデータ空間ハイパーサーバも指し示す、ファイルに対するＥＩＤを含む記録を取り出す。

名前空間ＨＭはまた、読み取るためのオープンか、書き込むためのオープンかを区別することによって、ファイルデータへのアクセスを提供すべきである、データ空間ハイパーサーバのＨＭも選択する。読み取るためのオープンに続く読み取りは、任意のデータ空間ＨＭへ進むことができる。名前空間ＨＭは、好適なものを選択するであろう。書き込むためのオープン後の読み取りおよび書き込みについては、選択されたデータ空間ＨＭは、ハイパーサーバ一次メンバーであろう。

次いで、名前空間ハイパーサーバのＨＭは、ステップ５で選択されたデータ空間ＨＭとともに、（ファイルを記憶するデータ空間ハイパーサーバも指し示す）ファイルに対するＥＩＤを含む記録を返すことによって、クライアント要求に応答する。同時に、これはまた、クライアントからの後続の入出力要求が、データにアクセスするために必要とする時間を最小化することができるように、ファイルがキャッシュに取り込まれるべきであることをデータ空間ハイパーサーバのＨＭに警告する。

データ空間ＨＭが後続の読み取り要求に応答しない場合、エラーに対処するために、読み取るためのオープンの場合であれば、クライアントが無作為に別のＨＭを選択できることに留意されたい。一方、オープンが書き込むためであった場合、データ空間一次メンバーが応答することを待つ必要がある（それは、元の一次メンバーがもはや利用可能ではなかった場合、データ空間ハイパーサーバの再構成を必要とし得る）。

最終的に、クライアントは、ステップ７で説明されるように、名前空間ＨＭが選択したものに対して要求を実行したデータ空間ＨＭが変化し得るため、要求を実行したデータ空間ＨＭに対するＳＩＤとともに、上記のステップ３で選択した名前空間ＨＭにクローズ要求を送信するであろう。名前空間ＨＭは、以前の入出力要求に対処したデータ空間ＨＭにクローズ要求を伝搬し、これが相互作用を完結する。

これに関して、全体として、どこで選択が行われようと、データ空間上のＨＭの選択が一貫していることを確認するように、同一のアルゴリズムが全面的に適用されることが重要である。

ここで、典型的な従来技術のＮＡＳシステム上の入出力動作のいくつかの具体例、およびＨｙｐｅｒｆｉｌｅｒを使用することに触れる。

図２は、４つのディレクトリレベルを含む、パス名を伴うファイルにアクセスするための従来技術のネットワークアタッチド記憶（ＮＡＳ）システムの典型である、ディスクおよびネットワーク入出力動作を図示する略図である。４つのディレクトリレベルが、典型的には、良好なディレクトリアクセス速度のために望ましくあり得る。ここで、パスは、「／ｍｎｔ／ｎｅｔａｐｐ／ａ／ｂ／ｃ／ｄ／Ｅ」であり、パスに沿った各ステップは、有意なアクティビティを要求する。ステップ１では、ルートへ進み、ｉ−ノードを読み取ることが必要である。次いで、ステップ２では、ルートデータは、「ａ」のｉ番号を取り出し、そのハンドルを返送するために使用される。ステップ３では、ハンドルは、「ａ」を参照し、「ａ」のｉ−ノードを読み取るために使用される。ステップ４では、取り出されたデータは、「ｂ」のｉ番号を取り出し、そのハンドルを返送するために使用される。ステップ５では、「ｂ」のハンドルは、そのｉ−ノードを読み取るために使用される。ステップ６では、取り出されたデータは、「ｃ」のｉ番号を取り出し、そのハンドルを返送するために使用される。ステップ７では、「ｃ」のハンドルは、そのｉ−ノードを読み取るために使用される。ステップ８では、取り出されたデータは、「ｄ」のｉ番号を取り出し、そのハンドルを返送するために使用される。ステップ９では、「ｄ」のハンドルは、そのｉ−ノードを読み取るために使用される。ステップ１０では、取り出されたデータは、「Ｅ」のｉ番号を取り出し、そのハンドルを返送するために使用される。最終的に、ステップ１１では、「Ｅ」のハンドルは、「Ｅ」のデータを読み取り、「Ｅ」のデータを返すために使用される。これらの動作のためのディスク入出力の総数は、１０であり、６つのネットワーク入出力がある。

図３は、図２と同一のパス名を伴うファイルにアクセスするために本発明の実施形態によるＨｙｐｅｒｆｉｌｅｒによって要求される、ディスクおよびネットワーク入出力動作を図示する略図である。この場合、クライアントは、ハッシュテーブル３０１を記憶している。ステップ１では、クライアントは、パス名のハッシュ３０１ａを決定し、ハッシュテーブル３０１にアクセスし、クライアントがその記憶要求を提示することができる関連名前空間ハイパーサーバを識別する、名前空間ハイパーサーバＩＤ３０１ｂを取得する。ステップ２では、クライアントは、識別された名前空間ハイパーサーバへのファイルオープン要求３０２ａを行い、識別された名前空間ハイパーサーバは、関連データ空間ハイパーサーバのハンドル３０２ｂおよびＩＤをクライアントに返す。ステップ３では、クライアントは、識別されたデータ空間ハイパーサーバへの読み取り要求３０３ａを行い、順に、識別されたデータハイパーサーバからデータ３０３ｂを取得する。これらの動作のために、単一のディスク入出力動作、および２つだけのネットワーク入出力動作がある。

図３では記憶読み取りを図示した一方で、図４では、記憶書き込みを図示する。したがって、図４は、パス名「ｘ／ｙ／ｚ０１２３４５６７８」を伴うファイルを作成するための本発明の実施形態によるＨｙｐｅｒｆｉｌｅｒにおける動作を図示する略図である。図４では、クライアントは、最初に、パス名のハッシュを作成し、記憶要求を行うためにどの名前空間ハイパーサーバを使用するかを決定するために、その記憶されたハッシュテーブル４０２を使用する。本実施例では、クライアントは、名前空間ハイパーサーバＨＳ０への要求を行うことを決定する。また、本実施例では、名前空間ハイパーサーバＨＳ０は、一次メンバー４２１と、二次メンバー４２２とを含む。一次メンバーは、記憶要求を得て、ステップ番号１では、名前空間エントリ３５をこの要求に割り付け、このエントリにパスデータを記憶し、次いで、名前空間エントリ３５をロックする。同様に、一次メンバー４２１は、ステップ２でファイルテーブルエントリ５１を作成し、ステップ３で文字列テーブルエントリ６６を作成する。ステップ４では、一次メンバー４２１は、連続番号５１３をこの書き込み要求に割り付け、データ空間ハイパーサーバＨＳ２（一次メンバー４３１および二次メンバー４３２を有する）を使用して、それをディスクに送信する。さらに、一次メンバーは、名前空間エントリ３５をロックする命令と、ＦＴエントリ５１およびＳＴエントリ６６のデータとを含む、シーケンス５１３についてのレポートを二次メンバー４２２に送信する。ステップ５では、（ステップ４で送信された命令を実行し、後に、シーケンスの開始時にロックしたノードエントリ３５をロック解除した）二次メンバー４２２から確認を受信した後、一次メンバーは、名前空間エントリ３５をロック解除する。ステップ６では、一次メンバーは、データ空間サーバＨＳ２から範囲ＩＤを要求し、さらに、作成要求が行われたことをクライアントに報告し、次いで、名前空間ハイパーサーバＨＳ０とさらに相互作用する必要なく、データ空間ハイパーサーバＨＳ２上で読み取りおよび書き込みを行うために、クライアントが使用されることができるであろうハンドルをクライアントに返す。

ＮＳエントリ３５をロックすることを参照して図４で説明しているが、ファイルが作成されるとき、種々の実施形態では、（１）他の動作が同時に同一のディレクトリ上で行われることを防止するため、および（２）親ディレクトリノードが、新しいファイルを表す新たに作成された子ノードを指し示すことを可能にするために、追加のロック、すなわち、名前空間内の親ディレクトリを表すノードのロックがある。ファイル動作が、単に既存のファイルの属性を変更するためである場合、親ディレクトリのロックは要求されず、影響を受けるノードのみがロックされる必要がある。前述の親ディレクトリの場合のように、追加のノードがロックされる必要がある場合、それを行う命令は、一次名前空間ハイパーサーバメンバー４２１がステップ４でその二次メンバー（メンバー４２２等）に送信する命令の一部である。

（ＩＩＩ．動作挙動）
本節は、システム完全性、故障、およびデータ回復に自動的に対処するために利用可能にされる設備とともに、Ｈｙｐｅｒｆｉｌｅｒの標準挙動を例証する。

（システム設定および管理）
Ｈｙｐｅｒｆｉｌｅｒは、それが約１０分で構成されること、および新しいＨＭが５分未満で追加されることを可能にする、単純なＧＵＩインターフェースを通して管理される。

Ｈｙｐｅｒｆｉｌｅｒのシステム管理コンポーネントは、監視および警告を含む、システムを自動的に管理するために必要とされる全てのサーバ側機能を果たす。

Ｈｙｐｅｒｆｉｌｅｒ設定は、最初に、各ＨＭが管理する記憶装置とともに、ＨＭをそれに割り当てることによって達成される。構成段階では、各ＨＭが常駐する物理的サーバも識別することが重要である。これは、それがどのＨＭが同一のハイパーサーバのメンバーになる良好な候補であるかをシステム管理に知らせるので、重要な情報であり、単一障害点（ＳＰＯＦ）を回避するために、各ハイパーサーバは、異なる物理的ノード上でホストされるＨＭで作成されなければならない。

同一の記憶層内で使用されるＨＭが、（ＲＡＭ、ＣＰＵ、およびネットワーク能力に関して）同等であるハードウェア上で作動すること、同一の種類の記憶装置（ＳＡＮ、ローカルドライブ等）に基づくこと、およびまさに同等の物理的ボリュームを管理することが重要である。これにおける大きな相違は、実際に、ハイパーサーバの性能をその最弱コンポーネントの性能まで低減させることによって、性能問題を引き起こし得る。

システム管理は、ＳＰＯＦが回避されていることを確認することによって、ハイパーサーバを集約する。システム管理は、同一の容量および能力を伴うＨＭを一緒にグループ化することも試みる。

（通常システム動作）
Ｈｙｐｅｒｆｉｌｅｒを使用することを所望するＬｉｎｕｘ（登録商標）クライアントは、カーネルローダブルモジュールをロードする必要がある。カーネルローダブルモジュールは、Ｌｉｎｕｘ（登録商標）システムが作動するにつれて、ロードおよびアンロードされることができるが、アンロード動作は、クライアントがＨｙｐｅｒｆｉｌｅｒにアクセスすることを止め、それを「アンマウント」したときのみ許可される（以下参照）。

カーネルモジュールがロードされてアクティブであると、クライアントは、ＮＦＳのように、ローカルファイルシステム（マウントポイント）内の空のディレクトリにマウント動作を行うことができる。その後、パス名がマウントポイントの下に到達するファイルまたはディレクトリへの任意のアクセスは、パス名をＨｙｐｅｒｆｉｌｅｒ内の適切なファイルシステムオブジェクトにマップしたカーネルモジュールを伴う。このプロセスは、アプリケーションに透過的である。同一または異なるＨｙｐｅｒｆｉｌｅｒに対する複数のマウントポイントが、同一のクライアント内で共存でき、クライアントが、ＮＦＳファイラディレクトリならびにＨｙｐｅｒｆｉｌｅｒをマウントできることに留意されたい。

上記で説明されるＰＯＳＩＸ意味論への軽微な制限が、そのようなアクセスに適用される。中でも注目すべきは、書き込むための第１のオープンは承認されるが、後続の要求は、ファイルが閉じられてファイルの現在のバージョンになるまでエラー（ＥＢＵＳＹエラー）を返すとうい点で、複数のスレッドは、同一のファイルへの同時書き込みアクセスを許可されない。一方で、ファイルが書き込むために開いている間、読み取るためのオープンは、ファイルの前のバージョンを自動的に参照するであろう。

ＨｙｐｅｒｆｉｌｅｒがＰＯＳＩＸ意味論を実装するという事実は、クライアント上で作動し、Ｈｙｐｅｒｆｉｌｅｒ内のファイルおよびディレクトリにアクセスする任意のアプリケーションが、いかなる変更も伴わずに作動することを示唆する。

Ｈｙｐｅｒｆｉｌｅｒは、ファイルへのＨＴＴＰ／ＨＴＴＰＳアクセスも利用可能にする。このため、このプロトコルをサポートするコンポーネントは、Ｈｙｐｅｒｆｉｌｅｒ内で作動し、各Ｈｙｐｅｒｆｉｌｅｒは、サブドメインサーバを実装する。したがって、Ｈｙｐｅｒｆｉｌｅｒがサポートするように構成されているサブドメインに対する名前を参照する任意の要求は、ＨＴＴＰ／ＨＴＴＰＳコンポーネントに直接渡される。サブドメインマネージャは、Ｈｙｐｅｒｆｉｌｅｒ全体にわたって負荷を分配するよう、全ての利用可能なそのようなコンポーネントにわたって、着信要求をラウンドロビンする。しかしながら、ＵＲＬの解釈において、サブドメインサーバは、目的とするオブジェクトを管理するハイパーサーバによって、要求を対処させようとする。

システムの将来のバージョンは、同様にＮＦＳアクセスをサポートするであろう。将来のＨｙｐｅｒｆｉｌｅｒバージョンはまた、ネイティブＨｙｐｅｒｆｉｌｅｒプロトコルを使用するＷｉｎｄｏｗｓ（登録商標）リダイレクタを供給することによって、Ｗｉｎｄｏｗｓ（登録商標）クライアントもサポートするであろう。

（エラー検出および回復）
Ｈｙｐｅｒｆｉｌｅｒは、分散型ファイルシステム内のファイルおよびディレクトリの完全性を監視し、おそらく生じる得る任意の非一貫性を検出することができる。ローカルの非一貫性は、即時に対処される。例えば、ハイパーサーバのメンバーが、ファイルを読み取っている間に入出力エラーを検出する場合、それは、即時にファイル範囲を不良としてマークし、ハイパーサーバの別のメンバーに要求を終えるように求め、ファイルのコンテンツを有効なコピーを有するメンバーのコンテンツと再同期させる。

（ハイパーボリュームおよびハイパーサーバ修復）
ハイパーサーバのメンバーは、そのハイパーボリュームインスタンスにおいて非一貫性を検出すると、非一貫性の性質に応じて、異なって作用することができる。軽微な非一貫性は、前の節で説明されるように、即座に対処されるべきである。しかしながら、名前空間のコンテンツまたはデータ空間のコンテンツが損なわれた場合、メンバーＨＭは、完全ハイパーボリューム再同期化をトリガすべきである。新しいＨＭがハイパーサーバに割り当てられるときに、同じことが起こる。

動作は、２つのステップで起こる。
・第１の段階は、名前空間が存在するはずであり、名前空間再同期化が必要とされる場合、名前空間を再同期させることになる。これは、ハイパーサーバ一次メンバー上で利用可能な持続的イメージに記憶されているような名前空間コンテンツをコピーすることを伴う。これは、システムが作動するにつれて行われる。プロセスの終了時に、一次メンバーは、新しいＨＭが完全に同期させられるまで、着信更新要求をしばらくの間保持する。この後、更新要求は、新しいメンバーと同様に有効にされる。（これが名前空間内でどのようにして達成されるかについての詳細は、「新しいメンバーの初期化」と題された上記の節にある。）
・第２の段階は、データ空間が、修復されているハイパーサーバのために存在する場合、データ空間に対する同様のタスクを達成する。

第１の段階は、修復される２つのリポジトリの相対的サイズにより、第２の段階より確かに高速であることに留意されたい。それでもなお、段階１の終了時に、その名前空間が完全に修復されるとすぐに、新しいメンバーは、要求にサービスを提供し始めることができる。段階２が完了するまで、新しいＨＭは、データ空間を伴う要求に返信せず、代わりに他のハイパーバイザメンバーに返信させるであろう。

ハイパーサーバの全てのメンバーが退去するか、またはクラッシュする場合において、そのハイパーサーバによってサポートされるファイルシステムオブジェクトは、利用不可能になるであろう。この理由により、十分な冗長性を伴ってシステムを構成することが極めて望ましい。そのような場合、システム管理は、ハイパーボリュームが高可用性ブロック記憶装置に依存している場合か、冗長性がローカルハードドライブ上にＨｙｐｅｒｆｉｌｅｒによって構築されるかで異なって動作する。

第１の場合において、システム管理は、単純に、利用可能なＨＭから新しいハイパーバイザを製造し、ハイパーサーバが所有する冗長記憶リソースにそれを割り当てなければならない。

しかしながら、記憶装置が非冗長ローカル記憶装置の複製を介して実装されている場合、システムは、元のハイパーバイザメンバーのうちの１つが再起動することを待ち、次いで、名前空間上の冗長性および利用可能なコピーからのデータの冗長性を再構築する。

（記憶層の間の移動）
複数の記憶層がＨｙｐｅｒｆｉｌｅｒ内に存在するとき、およびこの特徴が有効にされる場合、システムは、ファイルへのアクセスを監視する。顧客は、ファイル移動窓と呼ばれる、参照の時間窓を設定することを可能にされる。周期的に、システムは、各ハイパーサーバ内の名前空間を調べる。所与のファイルが最後の移動窓内で参照されていない場合、それは、下の記憶層へ移動させられる（下の記憶層が存在する場合）。有効にされている場合、システムはまた、下層内のファイルが参照される次のときに、ファイルを上の記憶層に移動させることも担当し、これは、ファイルが属すべき記憶層内にファイルを保つ。

（スクラビングおよびスカベンジング）
データが書き込まれると、ビット崩壊およびセクタ劣化が起こり得る。この理由により、システムは、既存のデータのスクラビングを行う。各ハイパーサーバ内の一次メンバーは、全てのメンバー上の各ハイパーボリュームの名前空間およびデータ部分を走査して、それらが同期化されていること、破損データがないこと、および孤立しているが誤動作により削除されていない任意のデータがパージされることを確認する。

これは、入出力集中アクティビティであり、最終的にハイパーサーバの全体的性能に影響を及ぼし得る。したがって、システムは、進行中である入出力の量を追跡しているので、これはシステムが高負荷でないときのみ起こり、かつＣＰＵ、ＲＡＭ、ディスク、およびネットワーク帯域幅の事前構成された割合を超えないように起こることを確認することができる。

（Ｈｙｐｅｒｆｉｌｅｒ拡張およびアップグレード）
そのアーキテクチャにより、Ｈｙｐｅｒｆｉｌｅｒは、本質的に拡張可能である。追加の記憶装置が必要とされるか、または追加の性能が要求されるときはいつでも、動的な様式で、つまり、継続中の動作を妨害することなく、新しいＨＭをＨｙｐｅｒｆｉｌｅｒに追加することが可能である。

その際に、以下の基準が順守されるべきである。
・所与の記憶装置クラスに追加されるＨＭの数は、そのクラスの基数の倍数となるべきである。所与の記憶層に追加されるＨＭは、利用可能なＲＡＭおよび記憶装置に関して同様の構成を有すべきであり、かつ同様の能力を伴うＣＰＵ上で作動すべきである。
・同一のハイパーサーバのメンバーが同一のマシン上で作動する状況を回避するよう、ＨＭがホストされるサーバの記述は、常に正確であるべきである。これは、実際に、ＨＭレベル冗長性が存在しないことをもたらすであろう。

また、記憶層内の基数の増加が同様に対処されることができることにも留意されたい。また、Ｈｙｐｅｒｆｉｌｅｒの固有冗長性を利用して、継続中の動作を妨害することなく、アップグレードを行うことができる。基本的に、１度に１つのＨＭがアップグレードされ、したがって、このプロセスが行われる場合、それらが属するハイパーサーバが動作し続けることを可能にする。

（本実施形態における制約および制限）
本明細書のＨｙｐｅｒｆｉｌｅｒアーキテクチャは、極めて一般的であり、展開の多くの変異形に適応することができる。しかしながら、初期リリースの開発を単純化するために、可能性な組み合わせの数を制約することが望ましい。本節は、そのような制限について議論する。

（ハイパーボリュームおよびハイパーサーバ）
名前空間サービスおよびデータ空間サービスの両方をサポートするＨＭを実装する際、特に、ＨＭをハイパーサーバに集約することを期待される、システム管理のために、展開を単純化する。しかしながら、直接アタッチドハードドライブ（この場合、直接アタッチド記憶デバイスの省略である「ＤＡＳＤ」を伴うものと称する）、ならびにＳＡＮまたはＳＡＮのようなインフラストラクチャを介してプロビジョニングされたＬＵＮを使用する必要があるので、以下によって引き起こされる、いくつかの複雑な事態が生じる。

ＳＡＮ上のＬＵＮは、概して高可用性であり、その結果、データ空間のための複製を提供することにおいて固有の価値はない。実際に、ＳＡＮ上のＬＵＮは、ＬＵＮが冗長性をすでに提供しハイパーサーバを介した追加の複製を必要としないので、記憶装置の無駄になるであろう。

名前空間は、少なくとも２に設定された基数を有するハイパーサーバを使用することによって、常に複製されるべきである。これは、ＨＭ再起動中に、名前空間のある部分が一時的にアクセスできなくなり得る確率を有意に低減させるので、望ましい。また、これは、複数のＨＭにわたって名前空間負荷を共有させることを可能にする。これらの考慮事項は、ＤＡＳＤ記憶装置および冗長ＬＵＮの両方に適用される。

次いで、ＬＵＮについては、名前空間を複製させるであろう一方で、データ空間は、Ｈｙｐｅｒｆｉｌｅｒ内で複製されないであろう。これは、ＤＡＳＤベースの実装の場合において両方のサービスが複製から利益を得るであろうから、ＳＡＮベースの実装とＤＡＳＤベースの実装との間の要件が分岐するという事実を明確に指し示す。ＨＭを独占的に名前空間サービスまたはデータ空間サービスのいずれか一方の専用にすることは、カーネルによって使用されるＲＡＭが各個々のＨＭのために増加させられるであろうため、いくつかのＨＭが両方をホストするときよりも多くのＲＡＭを要し得る。しかしながら、そのようなサービスの分離は、いくつかの利益も有するであろう。これは、例えば、ＤＡＳＤベースの構成およびＳＡＮベースの構成を同様に取り扱うことによって、ＨＭの作成および管理に単純化を追加するであろう。これは、名前空間サービスに関する問題が、同一のＨＭ内で共同ホストすることができるデータ空間サービスも停止させないように、より良好な故障隔離を提供するであろう。ＨＭで必要とされるカーネルデータの量は、確かに、ＨＭによって実行されるサービスの数および複雑性に厳密に相関するであろう。したがって、大まかに言うと、サービスがＨＭにおいて分離されるであろうかどうかにかかわらず、所与のサービスによって必要とされるカーネルＲＡＭの量がほぼ同一であろうことを期待することができる。最終的に、各ＨＭ内で使用されるカーネルイメージおよび実行ファイルのサイズを最小化することが確かに可能であり、カーネルコードページがＨＭにわたって共有され得るであろうことをハイパーバイザに知らせることが可能であり、これは、メモリ要件も減少させるであろう。全ての上記の考慮事項により、各ＨＭを両方ではなく名前空間サービスまたはデータ空間サービスのいずれか一方の専用にするように、Ｈｙｐｅｒｆｉｌｅｒの第１のリリースを有することが合理的と考えられる。

（各ＨＭの構成）
第１のＨｙｐｅｒｆｉｌｅｒリリースにおいて、各ＨＭが名前空間サービスまたはデータ空間サービスのいずれか一方をホストするであろうという事実に基づいて、リソースの割り付けを選択する際に、以下の基準が適用されるであろう：１０ＧＢのデータ空間が、名前空間サービスを実行する各ＨＭのために利用可能となるであろう。できる限り多くのドライブが、データ空間サービスを実行する各ＨＭのために利用可能となるであろう。ルートファイルシステムおよびスワップ領域のための十分な量の空間が、どちらのＨＭタイプのためにも利用可能となるであろう。約１．５ＧＢ〜２ＧＢのＲＡＭが、それが実行するサービスによって使用されるために各ＨＭに利用可能となるであろう。約８００ＭＢが、各ＨＭカーネルのために利用可能となるであろう。（これは最大値である。可能であれば、必要とされるコンポーネントの量を削減することによって、およびＨＭにわたってカーネルコードページを共有することによって、これはさらに縮小されるべきである。）コアのおよそ１／４が、各ＨＭ専用にされるであろう。およそ２つのＨＭが、各ドライブに割り付けられるであろう。

（結語）
Ｈｙｐｅｒｆｉｌｅｒは、本明細書の実施形態では、単一の名前空間を伴う高可用性スケールアウトファイルシステムを実装する。本システムは、理想的には、ウェブ規模アプリケーション向けの高可用性共有ファイル記憶プラットフォームを提供するために適しており、容量および性能、固有のボトルネックの欠如、および単一のディスク入出力動作でランダムセット内のファイルを開く能力に関して、無限拡張可能性を提供する。この最後の特性は、単独で、ほとんどのファイルについて１０倍の性能利点を伴い、ドライブスピンドルの総数の大幅な削減を可能にする。データ空間からの名前空間の分離は、それらが、ＳＡＴＡドライブまたはＳＳＤ等のアプリケーション環境のために最も適切である二次媒体上に配置されることを可能にする。これらの特性を伴うファイルシステムは、現代の業界標準サーバのコンポーネントに依存するトレードオフに基づき、したがって、マルチコアＣＰＵ、大量のＲＡＭ、高ネットワーク帯域幅、および低ネットワーク待ち時間の可用性を十分に利用する。本システムのための理想的な作業負荷は、データベース型アクセスが必要とされない、一般読み取りを伴う読み取り書き込みトラフィックから成る。本システムは、ＰＯＳＩＸ規格の順守を提供し、したがって、アプリケーション開発者がベンダー特有のＡＰＩにとらわれることから解放し、ＮＦＳに基づく既存のアプリケーションが変わりなく作動することを可能にする。Ｈｙｐｅｒｆｉｌｅｒが単一の名前空間内で無限に拡張できるという事実は、Ｈｙｐｅｒｆｉｌｅｒが単一のエンティティとして挙動して管理される際に、顧客が、全ての記憶デバイスに到達するために複雑なマウントマップに取り組む必要がないことを示唆する。名前空間専用のＲＡＭの量およびスワップデバイスの性質に関して、名前空間が対処される方法の融通性は、サポートされる記憶層の数およびタイプとともに、所望のコスト／性能比の極度の融通性が得られることを可能にする。

Ｈｙｐｅｒｆｉｌｅｒは、最大４メンバーのＨＭを伴うハイパーサーバに何千個ものＨＭを一緒に集約する。更新の調整は、単一のハイパーサーバ内で行われる必要しかない。したがって、従来のクラスタにおける直線性を破壊し、それらがサポートできるノードの数を制約する、通信の組み合わせ的爆発が、Ｈｙｐｅｒｆｉｌｅｒを制限しないため、本システムの性能は、直線的に拡大縮小することができる。従来のファイル名およびＰＯＳＩＸ意味論の使用は、アプリケーション開発者がファイル名を介して情報を伝えることを可能にする。これは、あるレベルで、常に名前および属性をオブジェクトＩＤに変換するために外部マッピング層に依存する必要があるオブジェクトストアと対比されることができる。ＨＡインフラストラクチャは、アプリケーション層内に複製特徴を組み込む必要性を回避する。ＨＭおよびそれらが使用する記憶デバイスへの依存は、特殊アプライアンスまたはアドホックハードウェアを購入しなければならないことからユーザを保護する。全体として、特に大規模ウェブアプリケーションのために設計されている、Ｈｙｐｅｒｆｉｌｅｒのようなシステムは、この市場区分が要求するトレードオフを達成することができる。Ｈｙｐｅｒｆｉｌｅｒは、大部分がそれ自体を自動的に管理するため、Ｈｙｐｅｒｆｉｌｅｒは、複雑性の低減、取得コストの低減、アプリケーションおよびインフラストラクチャ側の開発コストの低減、および運用コストの低減に関して、その革新的技術を主要な節約に具体的に変換する。これはまた、優れた性能および可用性も提供する。

別の関連実施形態では、クラスタによって管理されている名前空間データの共有サブセットに対する更新を取り扱う経過中に、そこへの各連続更新は、連続番号を与えられ、クラスタの論理コンピュータシステムは、連続番号に基づいて、事前定義された更新順を依然として保持しながら、非同期的に動作するように構成される。
本発明はさらに、例えば、以下を提供する。
（項目１）
複数の論理コンピュータシステム内でソフトウェア定義ネットワークアタッチ可能記憶システムを確立する方法であって、各コンピュータシステムは、メモリと、プロセッサと、記憶システムとを有し、
前記方法は、前記論理コンピュータシステム内でプログラムのセットを実行することを含み、
前記プログラムのセットは、名前空間内で動作する名前空間サーバとして論理コンピュータシステムの第１のセットを確立し、かつ、データ空間サーバとして論理コンピュータシステムの第２のセットを確立し、前記論理コンピュータシステムの第１のセットは、少なくとも２つの論理コンピュータシステムを含み、各論理コンピュータシステムは、前記名前空間の異なるパーティション内で自律的に動作するように構成され、
（ｉ）各名前空間サーバは、
（ａ）ファイルシステムメタデータをそのメモリに持続的に記憶することであって、前記ファイルシステムメタデータは、ファイルおよびディレクトリ名と、前記ファイルおよびディレクトリ名に関連付けられているユーザデータが常駐する場所についての情報とを含む、ことと、前記ファイルシステムメタデータの動的に更新されたコピーをその記憶システムに記憶することと、
（ｂ）そのメモリに持続的に記憶されている前記メタデータに基づいて、少なくとも１つの要求クライアントコンピュータからの前記名前空間の所定のサブセットに対する記憶システムパス名要求を処理することと、各要求に応答して、前記要求クライアントコンピュータによる使用のためのハンドルを返送することと
を行うように構成され、前記名前空間サーバの全ては、集合的に、したがって、前記名前空間の全体に対する記憶システムパス名要求を処理し、
（ｉｉ）各データ空間サーバは、前記名前空間サーバによって決定され、前記少なくとも１つの要求クライアントコンピュータから受信されるハンドルに直接基づいて、ユーザデータをその記憶システムに記憶し、取り出すように構成されている、方法。
（項目２）
前記名前空間サーバの少なくとも１つの厳密なサブセットは、前記名前空間の共有サブセットに対して記憶システムパス名要求を処理するために、クラスタとして動作するように構成され、前記名前空間の前記共有サブセットに対するファイルシステムメタデータは、前記クラスタ内の各名前空間サーバのメモリの中に持続的に常駐している、項目１に記載の方法。
（項目３）
前記クラスタ内の名前空間サーバの数は、予測負荷条件下で、所望のレベルの速度、冗長性、および可用性を達成するように選択される、項目２に記載の方法。
（項目４）
前記データ空間サーバの少なくとも１つの厳密なサブセットは、前記データ空間の共有サブセットに対して、前記名前空間サーバによって決定されるハンドルに基づいて、ユーザデータをその記憶システムに記憶し、取り出すために、クラスタとして動作するように構成されている、項目１に記載の方法。
（項目５）
前記クラスタ内のデータ空間サーバの数は、予測負荷条件下で、所望のレベルの速度、冗長性、および可用性を達成するように選択される、項目４に記載の方法。
（項目６）
前記論理コンピュータシステムのうちの少なくともいくつかは、仮想コンピュータシステムである、項目１に記載の方法。
（項目７）
前記論理コンピュータシステムのうちの少なくともいくつかは、仮想コンピュータシステムである、項目２に記載の方法。
（項目８）
前記論理コンピュータシステムの全ては、仮想コンピュータシステムである、項目２に記載の方法。
（項目９）
前記論理コンピュータシステムのうちの少なくともいくつかは、仮想コンピュータシステムである、項目４に記載の方法。
（項目１０）
前記論理コンピュータシステムの全ては、仮想コンピュータシステムである、項目４に記載の方法。
（項目１１）
前記論理コンピュータシステムの第１および第２のセットは、互いに素である、項目１に記載の方法。
（項目１２）
前記論理コンピュータシステムの第１および第２のセットは、互いに素ではない、項目１に記載の方法。
（項目１３）
前記ファイルシステムメタデータは、パス名の共有プレフィックスがコンパクトに記憶されるように、パトリシア木データ構造に従って構造化される、項目１に記載の方法。
（項目１４）
前記ファイルシステムメタデータは、（ｉ）前記パトリシア木を符号化するノードテーブル、および（ｉｉ）ファイルおよびディレクトリの属性を符号化するファイルテーブル、および（ｉｉｉ）前記ノードテーブルで使用される最大長より大きい長さを有する、文字列の名前を符号化する文字列テーブルに記憶される、項目１３に記載の方法。
（項目１５）
前記ノードテーブル、前記ファイルテーブル、および前記文字列テーブルの各々は、持続性のために異なるファイルに動的に記憶される、項目１４に記載の方法。
（項目１６）
前記ノードテーブル、前記ファイルテーブル、または前記文字列テーブルのうちの任意のものに対する任意の変更は、インテントログに記憶され、前記インテントログは、そのようなテーブルに対応する前記ファイルを更新するために動的に使用され、単一の動作に関連する前記変更のうちの任意のものは、一緒に結び付けられる、項目１５に記載の方法。
（項目１７）
前記クラスタによって管理されている名前空間データの前記共有サブセットに対する更新を取り扱う経過中、前記共有サブセットに対する各連続更新は、連続番号を与えられ、前記クラスタの論理コンピュータシステムは、前記連続番号に基づいて、事前定義された更新順を依然として保持しながら、非同期的に動作するように構成されている、項目２に記載の方法。
（項目１８）
前記ノードテーブル、前記ファイルテーブル、および前記文字列テーブルの各々は、固定サイズのエントリを有する異なるアレイである、項目１４に記載の方法。

Claims (18)

1. 複数の論理コンピュータシステム内でソフトウェア定義ネットワークアタッチ可能記憶システムを確立する方法であって、各コンピュータシステムは、メモリと、プロセッサと、記憶システムとを有し、
   前記方法は、前記論理コンピュータシステム内でプログラムのセットを実行することを含み、
   前記プログラムのセットは、名前空間内で動作する名前空間サーバとして論理コンピュータシステムの第１のセットを確立し、かつ、データ空間サーバとして論理コンピュータシステムの第２のセットを確立し、前記論理コンピュータシステムの第１のセットは、少なくとも２つの論理コンピュータシステムを含み、各論理コンピュータシステムは、前記名前空間の異なるパーティション内で自律的に動作するように構成され、
   （ｉ）各名前空間サーバは、
   （ａ）ファイルシステムメタデータをそのメモリに持続的に記憶することであって、前記ファイルシステムメタデータは、ファイルおよびディレクトリ名と、前記ファイルおよびディレクトリ名に関連付けられているユーザデータが常駐する場所についての情報とを含む、ことと、前記ファイルシステムメタデータの動的に更新されたコピーをその記憶システムに記憶することと、
   （ｂ）そのメモリに持続的に記憶されている前記メタデータに基づいて、少なくとも１つの要求クライアントコンピュータからの前記名前空間の所定のサブセットに対する記憶システムパス名要求を処理することと、各要求に応答して、前記要求クライアントコンピュータによる使用のためのハンドルを返送することと
   を行うように構成され、前記名前空間サーバの全ては、集合的に、したがって、前記名前空間の全体に対する記憶システムパス名要求を処理し、
   （ｉｉ）各データ空間サーバは、前記名前空間サーバによって決定され、前記少なくとも１つの要求クライアントコンピュータから受信されるハンドルに直接基づいて、ユーザデータをその記憶システムに記憶し、取り出すように構成されている、方法。
2. 前記名前空間サーバの少なくとも１つの厳密なサブセットは、前記名前空間の共有サブセットに対して記憶システムパス名要求を処理するために、クラスタとして動作するように構成され、前記名前空間の前記共有サブセットに対するファイルシステムメタデータは、前記クラスタ内の各名前空間サーバのメモリの中に持続的に常駐している、請求項１に記載の方法。
3. 前記クラスタ内の名前空間サーバの数は、予測負荷条件下で、所望のレベルの速度、冗長性、および可用性を達成するように選択される、請求項２に記載の方法。
4. 前記データ空間サーバの少なくとも１つの厳密なサブセットは、前記データ空間の共有サブセットに対して、前記名前空間サーバによって決定されるハンドルに基づいて、ユーザデータをその記憶システムに記憶し、取り出すために、クラスタとして動作するように構成されている、請求項１に記載の方法。
5. 前記クラスタ内のデータ空間サーバの数は、予測負荷条件下で、所望のレベルの速度、冗長性、および可用性を達成するように選択される、請求項４に記載の方法。
6. 前記論理コンピュータシステムのうちの少なくともいくつかは、仮想コンピュータシステムである、請求項１に記載の方法。
7. 前記論理コンピュータシステムのうちの少なくともいくつかは、仮想コンピュータシステムである、請求項２に記載の方法。
8. 前記論理コンピュータシステムの全ては、仮想コンピュータシステムである、請求項２に記載の方法。
9. 前記論理コンピュータシステムのうちの少なくともいくつかは、仮想コンピュータシステムである、請求項４に記載の方法。
10. 前記論理コンピュータシステムの全ては、仮想コンピュータシステムである、請求項４に記載の方法。
11. 前記論理コンピュータシステムの第１および第２のセットは、互いに素である、請求項１に記載の方法。
12. 前記論理コンピュータシステムの第１および第２のセットは、互いに素ではない、請求項１に記載の方法。
13. 前記ファイルシステムメタデータは、パス名の共有プレフィックスがコンパクトに記憶されるように、パトリシア木データ構造に従って構造化される、請求項１に記載の方法。
14. 前記ファイルシステムメタデータは、（ｉ）前記パトリシア木を符号化するノードテーブル、および（ｉｉ）ファイルおよびディレクトリの属性を符号化するファイルテーブル、および（ｉｉｉ）前記ノードテーブルで使用される最大長より大きい長さを有する、文字列の名前を符号化する文字列テーブルに記憶される、請求項１３に記載の方法。
15. 前記ノードテーブル、前記ファイルテーブル、および前記文字列テーブルの各々は、持続性のために異なるファイルに動的に記憶される、請求項１４に記載の方法。
16. 前記ノードテーブル、前記ファイルテーブル、または前記文字列テーブルのうちの任意のものに対する任意の変更は、インテントログに記憶され、前記インテントログは、そのようなテーブルに対応する前記ファイルを更新するために動的に使用され、単一の動作に関連する前記変更のうちの任意のものは、一緒に結び付けられる、請求項１５に記載の方法。
17. 前記クラスタによって管理されている名前空間データの前記共有サブセットに対する更新を取り扱う経過中、前記共有サブセットに対する各連続更新は、連続番号を与えられ、前記クラスタの論理コンピュータシステムは、前記連続番号に基づいて、事前定義された更新順を依然として保持しながら、非同期的に動作するように構成されている、請求項２に記載の方法。
18. 前記ノードテーブル、前記ファイルテーブル、および前記文字列テーブルの各々は、固定サイズのエントリを有する異なるアレイである、請求項１４に記載の方法。