どこでも書き込み可能なファイルレイアウト

Write Anywhere File Layout ( WAFL )は、大規模で高性能なRAIDアレイ、クラッシュや停電の際に長時間の整合性チェックを行わずにすばやく再起動すること、およびファイルシステムのサイズをすばやく拡張することをサポートする独自のファイルシステムです。これは、NetApp FAS、AFF、Cloud Volumes ONTAP、ONTAP Selectなどのストレージアプライアンスで使用するためにNetAppによって設計されました。

WAFL の作者は、WAFL はファイルシステムではないと主張していますが、ファイルシステムを含んでいます。^{[3] WAFL は、NVRAM または NVMEM と呼ばれる専用のメモリストレージデバイスの}不揮発性ランダムアクセスメモリ内のログ (NVLOG と呼ばれる) として、ジャーナリングファイルシステムと同様に変更を追跡します。WAFL は、ディスクブロックにアクセスするさまざまなファイルシステムとテクノロジを有効にするメカニズムを提供します。

WAFL は、データだけでなくメタデータもファイルに保存します。ボリューム内のどのブロックが割り当てられているかを示す inode やブロック マップなどのメタデータは、ファイル システム内の固定された場所に保存されません。ボリューム内の最上位ファイルは inode ファイルで、他のすべてのファイルのinodeが含まれます。inode ファイル自体の inode はルート inode と呼ばれ、固定された場所のブロックに保存されます。十分に小さいファイルの inode にはファイルの内容が含まれます。それ以外の場合は、ファイル データ ブロックへのポインタのリスト、またはファイル データ ブロックへのポインタのリストを含む間接ブロックへのポインタのリストなどが含まれます。間接ブロックは必要な数だけレイヤー化され、ブロックのツリーが形成されます。ファイル システム内のすべてのデータ ブロックとメタデータ ブロックは、ルート inode を含むブロックを除き、ファイル システム内のファイルに保存されます。したがって、ルート inode は、inode ファイル以外のすべてのファイルのすべてのブロックを見つけるために使用できます。^[4]

メイン メモリは、ファイルからのブロックのページ キャッシュとして使用されます。ファイルのブロックに変更が加えられると、ページ キャッシュ内のコピーが更新され、ダーティとしてマークされ、その違いが NVLOG と呼ばれるログに不揮発性メモリに記録されます。ページ キャッシュ内のダーティ ブロックが永続ストレージに書き込まれる場合、そのブロックは読み取られたブロックに書き直されるのではなく、永続ストレージ上に新しいブロックが割り当てられ、ブロックの内容が新しい場所に書き込まれ、問題のブロックを指していた inode または間接ブロックがメイン メモリ内で更新されます。inode を含むブロックまたは間接ブロックが永続ストレージに書き込まれる場合、そのブロックも新しい場所に書き込まれ、以前の位置で上書きされることはありません。これが、「Write Anywhere File Layout」の「Write Anywhere」が指すものです。^[4]

ルート inode を含むブロック以外のすべてのブロックはルート inode を介して見つかるため、ルート inode が更新されるまで、永続ストレージに書き込まれた変更は永続ストレージ上では表示されません。ルート inode は、整合性ポイントと呼ばれるプロセスによって更新されます。このプロセスでは、永続ストレージにまだ書き込まれていないすべてのダーティ ブロックが永続ストレージに書き込まれ、新しいバージョンの inode ファイル内のブロックを指す新しいルート inode が書き出されます。その時点で、ファイル システムに対するすべての変更は、新しいルート inode を使用して永続ストレージ上で表示されます。現在表示されている変更の NVLOG エントリは、後続の変更のログ エントリ用のスペースを確保するために破棄されます。整合性ポイントは、定期的に、または不揮発性メモリがログ エントリでいっぱいになりそうになった場合に実行されます。^[4]

ファイル システムへのすべての変更が整合性ポイントで表示される前にサーバーがクラッシュした場合、表示されていない変更は NVLOG に残ります。サーバーが再起動すると、NVLOG 内のすべてのエントリが再生され、変更が NVLOG に記録されるため、変更が失われることはありません。

上で説明したように、WAFL はデータやメタデータをディスク上の所定の場所に保存しません。代わりに、時間的局所性を使用してデータを自動的に配置し、シングルおよびデュアル パリティ ベースの RAID を使用して安定したディスク ストレージにデータをコミットするために必要なディスク操作の数を最小限に抑えるように設計された方法で、ユーザー データと一緒にメタデータを書き込みます。

参照の時間的局所性に基づくデータ配置を使用すると、書き込まれた方法と同様の方法で読み取られるデータセット (データベース レコードとそれに関連付けられたインデックス エントリなど) の読み取りパフォーマンスが向上しますが、参照の空間的局所性の観点からは断片化が発生する可能性もあります。回転するHDDでは、これは、順次書き込まれるファイル、ランダムに読み取られるファイル、または同じ時間パターンを使用して後で読み取られるファイルに悪影響を及ぼしませんが、ランダム書き込み後の順次読み取りの空間データ アクセス パターンには影響します。これは、磁気ヘッドがプラッターからデータを読み取るために一度に 1 つの位置にしかいられないためです。一方、断片化はSSDドライブには影響しません。

ONTAP 7.3.1 以降のリリースには、スケジュールされた手動のデフラグを実行するreallocateコマンドや、空間の断片化によって生じる最適でないデータ アクセス パターンを検出して自動的に修正するWrite after Readingボリューム オプションなど、空間データ レイアウトを最適化するためのさまざまな手法が含まれています。ONTAP 8.1.1 のリリースには、ファイルシステム内の連続した空き領域を自動的に最適化するその他の手法も含まれており、ほとんどのデータ アクセス パターンで最適なデータ レイアウトを維持するのにも役立ちます。7G より前では、wafl scan reallocateコマンドは高度な権限レベルから呼び出す必要があり、スケジュールすることはできませんでした。ONTAP 9.1 以降のリリースには、SSDの使用を最適化するためのさまざまな手法が含まれています。たとえば、ONTAP 9.2 FabricPool機能から始まるインライン データ コンパクション (9.1 で開始) では、SSDアグリゲートで必要な場合にコールド データを低速の S3 ストレージに自動的に階層化し、その逆も行います。また、アグリゲートごとに最大 800TiB のアグリゲート内でのクロス ボリューム重複排除も含まれています。 ^[5]

WAFL は、ファイルシステムの読み取り専用コピーであるスナップショットをサポートしています。スナップショットは、整合性ポイントで実行されるのと同じ操作を実行して作成されますが、ファイルシステムの現在の状態に対応するルート inode を更新する代わりに、ルート inode のコピーを保存します。ファイルシステム内のすべてのデータとメタデータはルート inode から見つけることができるため、スナップショットが作成された時点のファイルシステム内のすべてのデータとメタデータは、スナップショットのルート inode のコピーから見つけることができます。スナップショットを作成するために他のデータをコピーする必要はありません。^[4]

ブロックは、どのブロックが使用中でどのブロックが空いているかを追跡するブロック マップを使用して書き込まれるときに割り当てられます。ブロック マップのエントリには、ブロックが現在のバージョンのファイル システムで使用中かどうかを示すビットと、スナップショットごとに 1 つずつ、スナップショットでブロックが使用中かどうかを示す複数のビットが含まれます。これにより、スナップショットが削除されるまでスナップショットのデータが上書きされないことが保証されます。ブロック マップを使用すると、すべての新しい書き込みと書き換えは新しい空のブロックに書き込まれ、WAFL はブロックの書き換えが成功したことのみを報告しますが、実際には書き換えは行われません。このアプローチは Redirect-on-write (ROW) 手法と呼ばれます。^{[4] ROW は}、Copy-on-writeと比較して書き換え操作がはるかに高速です。Copy -on-writeでは、インプレースで書き換えられ、スナップショットにキャプチャされる古いデータ ブロックは、元のデータを保持するために、まずスナップショット リザーブ用に割り当てられた領域にコピーされる必要があります。これにより、システムがそのブロックに書き換えられると、追加のデータ コピー操作が生成されます。

スナップショットは、ファイルシステム内の特別な隠しディレクトリを通じて迅速にアクセスできるオンラインバックアップを提供し、ユーザーが誤って削除または変更されたファイルを回復できるようにします。^[4]

NetApp の Data ONTAP リリース 7G オペレーティング システムは、 FlexClone と呼ばれる読み取り/書き込みスナップショットをサポートしています。スナップショットは、 SnapMirror、SnapVault、Online Volume Moveなどのテクノロジの基礎であり、 FlexClone、SnapLock、SnapRestoreなどの機能は、WAFL 機能や inode の操作などのプロパティを活用するスナップショットのようなテクノロジです。ONTAP 9.4 以降では、FlexVol ごとにサポートされるスナップショットの最大数は 1024 ですが、以前のバージョンでは最大制限は 255 でした。

ONTAP 9.5 以降では、アクティブ ファイル システムとスナップショット全体で重複排除スキャンを実行するためのスナップショット共有機能が追加され、重複排除による節約はスナップショットの数の大きさに応じて決まります。9.5 より前では、スナップショットにロックされた重複排除されていないデータは重複排除プロセスで使用できず、アクティブ ファイル システムでのみ実行されます。

WAFL の重要な機能は、NFSクライアント用のUnixスタイルのファイルおよびディレクトリ モデルと、 SMBクライアント用のMicrosoft Windowsスタイルのファイルおよびディレクトリ モデルの両方をサポートしていることです。WAFL は、同じボリューム上の異なるファイルに異なるセキュリティ属性を関連付けることができるモードを含め、両方のセキュリティ モデルもサポートしています。Unix は^[6]アクセス制御リスト(ACL) または単純なビットマスクのいずれかを使用できますが、最近の Windows モデルはアクセス制御リストに基づいています。これらの 2 つの機能により、SMB タイプのネットワーク ファイル システムにファイルを書き込んで、後で Unix ワークステーションから NFS 経由でそのファイルにアクセスすることが可能になります。通常のファイルに加えて、WAFL には、ブロック デバイスの LUN シリアル番号などの必要な特殊属性を持つLUNと呼ばれるファイル コンテナを含めることができ、 ONTAP OS ソフトウェアで実行されるSANプロトコルを使用してアクセスできます。

各フレキシブル ボリューム (FlexVol) は、アグリゲート上に配置され、アグリゲート内のすべてのディスクに分散された個別の WAFL ファイル システムです。各アグリゲートには複数の FlexVol ボリュームを含めることができ、通常は複数の FlexVol ボリュームがあります。ONTAP は、整合性ポイント (NVRAM を参照) で終了する「テトリス」を含むデータ最適化プロセス中に、各 FlexVol ボリュームに可能な限り均等にデータ ブロックをアグリゲート内のすべてのディスクに分散するようにプログラムされているため、各 FlexVol は、アグリゲート内のすべてのデータ ディスクの利用可能なパフォーマンスをすべて使用できる可能性があります。アグリゲート内のすべてのデータ ディスクに均等にデータ ブロックを分散するというアプローチにより、FlexVol のパフォーマンス スロットリングはストレージ QoS を使用して動的に実行でき、パフォーマンスを保証し、未使用のパフォーマンスを必要とする FlexVol ボリュームに提供するために、各 FlexVol に専用のアグリゲートまたは RAID グループを用意する必要はありません。各 FlexVol は、シック プロビジョニングまたはシン プロビジョニングされたスペースとして構成でき、後でいつでもオンザフライで変更できます。iSCSI、ファイバ チャネル（FC）、ファイバ チャネル オーバー イーサネット（FCoE）などのストレージ エリア ネットワーク（SAN）プロトコルを使用したブロック デバイス アクセスは、FlexVol ボリューム上のループ デバイス技術に似た LUN エミュレーションによって行われます。そのため、WAFL ファイル システム上の各 LUN はファイルとして表示されますが、ブロック デバイスに必要な追加のプロパティを持ちます。LUN は、シック プロビジョニングまたはシン プロビジョニングとして設定することもでき、後で実行中に変更できます。WAFL アーキテクチャにより、FlexVol および LUN は、設定されたスペース使用量をその場で増減できます。FlexVol にデータが含まれている場合、内部スペースは使用済みスペースと同じかそれ以上に減らすことができます。WAFL ファイル システムではデータを含む LUN のサイズを小さくできますが、 SAN アーキテクチャによりONTAP は上位レベルのブロック構造を認識しないため、データが切り捨てられ、その LUN 上のファイル システムが破損する可能性があります。そのため、ホストはデータを含むブロックを新しい LUN 境界に移行してデータ損失を防ぐ必要があります。各 FlexVol には、独自のQoS、FlashPool、FlasCache、またはFabricPoolポリシーを設定できます。

2 つの FlexVol ボリュームがそれぞれ 2 つのアグリゲート上に作成され、それらのアグリゲートが 2 つの異なるコントローラによって所有されている場合、システム管理者は NAS プロトコルを介してこれらのボリュームのスペースを使用する必要があります。次に、各ボリュームに 1 つずつ、2 つのファイル共有を作成します。この場合、管理者はおそらく異なる IP アドレスも作成します。それぞれが専用のファイル共有へのアクセスに使用されます。各ボリュームには 1 つの書き込みアフィニティがあり、スペースのバケットは 2 つあります。2 つのボリュームが 1 つのコントローラ上に存在し、たとえば 1 つのアグリゲート上にある場合 (したがって、2 番目のアグリゲートが存在する場合、この場合は使用されません)、両方のボリュームに 1 つの IP アドレスを介してアクセスする場合でも、各ボリュームに 1 つずつ、書き込みアフィニティが 2 つ存在し、スペースのバケットは常に 2 つ別々に存在します。したがって、ボリュームの数が多いほど、書き込みアフィニティが多くなります (並列化が向上し、CPU 使用率が向上します)。ただし、複数のボリューム (およびスペースのバケットが複数あるため、ファイル共有も複数) が存在することになります。

RAID 1と同様に、 ONTAP システムのプレックスはミラーリングされたデータを 2 か所に保存できますが、従来の RAID-1 は 1 つのストレージ システムの境界内に存在する必要がありますが、2 つのプレックスを 2 つのストレージ システム間に分散できます。各アグリゲートは 1 つまたは 2 つのプレックスで構成されます。従来の HA ストレージ システムでは、アグリゲートごとにプレックスが 1 つしかありませんが、SyncMirror ローカル構成または MetroCluster 構成では、アグリゲートごとにプレックスが 2 つあります。一方、各プレックスには、 RAID 0と同様に、1つ以上の NetApp RAID グループまたはサードパーティ製ストレージ システム ( FlexArray を参照) の LUN の基盤となるストレージ領域が 1 つのプレックスに含まれています。アグリゲートが 2 つのプレックスで構成されている場合、1 つのプレックスはマスター、もう 1 つはスレーブと見なされます。スレーブは、まったく同じ RAID 構成とドライブで構成されている必要があります。たとえば、アグリゲートが 2 つのプレックスで構成され、マスター プレックスが RAID-TEC で 21 台のデータ ドライブと 3 台の 1.8 TB SAS パリティ ドライブで構成されている場合、スレーブ プレックスは RAID-TEC で 21 台のデータ ドライブと 3 台の 1.8 TB SAS パリティ ドライブで構成されている必要があります。2 番目の例では、アグリゲートが 2 つのプレックスで構成され、マスター プレックスが RAID-TEC として構成された 1 つの RAID 17 データ ドライブと 3 台のパリティ SAS ドライブ (1.8 TB) で構成され、マスター プレックスの 2 番目の RAID が 2 つのデータ ドライブと 2 つのパリティ SSD (960 GB) を含む RAID-DP である場合です。2 番目のプレックスは同じ構成である必要があります。つまり、RAID-TEC として構成された 1 つの RAID 17 データ ドライブと 3 つのパリティ SAS ドライブ (1.8 TB) であり、スレーブ プレックスの 2 番目の RAID が 2 つのデータ ドライブと 2 つのパリティ SSD (960 GB) を含む RAID-DP です。MetroCluster 構成では、同期データ レプリケーションに SyncMirror テクノロジーが使用されます。 SyncMirror には、MetroCluster と Local SyncMirror の 2 つのオプションがあります。どちらも、2 つのプレックス間でのデータの同期レプリケーションに同じプレックス技術を使用します。Local SyncMirror は、1 つのコントローラに両方のプレックスを作成し、ストレージ システム内のディスク シェルフ全体の障害を防ぐための追加のセキュリティとしてよく使用されます。MetroCluster を使用すると、2 つのストレージ システム間でデータをレプリケートできます。各ストレージ システムは、1 つのコントローラで構成することも、2 つのコントローラで HA ペアとして構成することもできます。1 つの HA ペアでは、2 つのコントローラを別々のシャーシに配置することが可能で、互いの距離は数十メートルになる場合がありますが、MetroCluster 構成では距離は最大 300 km になります。

多くの競合他社と同様に、NetApp ONTAPシステムは、ホストからのデータを受け取ってキャッシュするためのはるかに高速なストレージメディアとしてメモリを使用し、最も重要な書き込み前のデータ最適化を行って、そのようなストレージシステムのパフォーマンスを大幅に向上させます。競合他社は、書き込みキャッシュとデータ最適化の両方のために、再起動などの予期しないイベント中にデータを保持するために不揮発性ランダムアクセスメモリ（NVRAM）を広く使用していますが、NetApp ONTAPシステムでは、データ最適化に通常のランダムアクセスメモリ（RAM）を使用し、リレーショナルデータベースで行われるトランザクションログと同様に、ホストからの初期データを変更されていない状態でログに記録するために専用のNVRAMまたはNVDIMMを使用しています。そのため、災害が発生した場合、当然、再起動後にRAMは自動的にクリアされ、NVLOGと呼ばれるログの形式で不揮発性メモリに保存されたデータは再起動後も存続し、一貫性の復元に使用されます。ONTAPシステムでのすべての変更と最適化はRAM内でのみ行われるため、ONTAPシステムの不揮発性メモリのサイズを削減できます。最適化後、テトリスのような方法で構造化されたホストからのデータは、いくつかの段階 (WAFL および RAID) を経て最適化および準備され、データが格納されるアグリゲートの RAID グループ内の基礎ディスクに書き込まれます。最適化後、データは整合性ポイント (CP) トランザクションの一部としてディスクに順次書き込まれます。アグリゲートに書き込まれるデータには、必要な WAFL メタデータとRAIDパリティが含まれるため、従来の RAID-6 および RAID-4 グループのように、データ ディスクからの追加読み取り、計算、パリティ ディスクへの書き込み操作は発生しません。CP は、最初にデータが書き込まれるアグリゲートにシステム スナップショットを作成し、次に RAM から最適化および準備されたデータを単一のトランザクションとして順次アグリゲートに書き込みます。これが失敗すると、突然の再起動時にトランザクション全体が失敗し、WAFL ファイル システムが常に一貫性を保つことができます。CP トランザクションが成功すると、新しいアクティブ ファイル システム ポイントが伝播され、対応する NVLOG がクリアされます。すべてのデータは常に新しい場所に書き込まれ、再書き込みは発生しません。ホストによって削除されたデータ ブロックは空きとしてマークされ、次回の CP サイクルで使用できるようになり、WAFL の「常に新しいデータを新しい場所に書き込む」ポリシーにより、システムのスペースが不足することはありません。HA ストレージ システム内の NVLOG のみが 2 つのコントローラ間で同期的にレプリケートされ、HA ストレージ システムのフェイルオーバー機能により、システム全体のメモリ保護オーバーヘッドが削減されます。HA 構成またはMetroClusterの 2 つのコントローラを備えたストレージ システムでは、各サイトに1つのコントローラがあり、2つのコントローラのそれぞれが自身の不揮発性メモリをローカルとパートナーの2つの部分に分割します。4つのノードを持つMetroCluster構成では、各不揮発性メモリはローカル、ローカルパートナー、リモートパートナーの3つの部分に分割されます。^[7]

NetApp は、All-Flash FAS A800 システム以降、NVRAM PCI モジュールをメモリ バスに接続された NVDIMM に置き換え、パフォーマンスを向上させました。

• ファイルシステムの比較
• ファイルシステムのリスト
• ネットアップ
• ネットアップFAS
• NetApp ストレージ システムで使用されるONTAPオペレーション システム

• 公式サイト
• NFS ファイル サーバー アプライアンスのファイル システム設計 (PDF)
• 米国特許 5,819,292 -ファイルシステムの一貫した状態を維持し、ファイルシステムのユーザーがアクセス可能な読み取り専用コピーを作成する方法- 1998 年 10 月 6 日