WAFLファイルシステム-NetApp Foundation

このブログの最初の投稿で、「技術的な側面から」NetAppについてお話しすることを約束しました。 ただし、NetAppシステムで使用できるほとんどの機能について説明する前に、「基礎」、NetAppストレージシステムの中心にあるもの、伝統的に「WAFLファイルシステム」と呼ばれる特別なデータ編成構造について説明する必要があります。どこでもファイルレイアウト-文字通りに翻訳されたRecord Everywhereを使用したファイル構造。

このテキストが「Habrにとってドライ」であることがわかった場合、辛抱強く、さらに興味深いものになりますが、実用的な「NetApp」機能の大部分の基盤にあるデバイスについては説明できません。 将来的には、以下の投稿で、より実用的な「チップ」についての詳細な説明を「興味がある人のために」参照する場所があるでしょう。
何らかの方法ですが、NetAppが独自の成長方法を知っているほとんどすべては、ファイルシステムであるNetwork Applianceのスタートアップの共同設立者であるDavid HitzとJames Lauによって90年代初期に発明されたアイデアから正確に成長します。 製品の当初有能で考え抜かれた「アーキテクチャ」の将来の開発がどれほど重要で有用であるかについての良い議論が判明するかもしれません。


しかし、まず、NetAppが独自のファイルシステムを必要としたのはなぜですか？当時の既存のファイルシステムが彼に合わなかったのはなぜですか？ NetAppの作成者の1人、Dave Hitzの共同設立者でありCTOの言葉は次のとおりです。

「当初は、独自のファイルシステムを作成するつもりはありませんでした。 Berkeley FFSが非常に適しているように思われました。 しかし、それに固有のいくつかの固有の問題がすぐに私たち自身のファイルシステムに取り組むことを余儀なくされました。

その時点でFFSを使用して緊急シャットダウン（fsck）が発生した場合のファイルシステムの整合性のテストは、受け入れがたいほど低速でした。 ファイルシステムのサイズが大きくなると状況が悪化し、すべてのディスクを単一のディスクボリュームに結合して単一のスペースを確保するというアイデアは事実上不可能になりました。

デバイスをできるだけ使いやすくしたかったのです。 これを行うには、すべてのディスクを単一のファイルシステムに結合する必要がありました。 当時（90年代の初め、プリムトラックについて話している）、人々は通常、それぞれのディスク上に別個のファイルシステムを作成し、それらを共通のツリーに一緒にマウントしました。これは不便で普遍的ではありませんでした。

共通のファイルシステムを使用して、一度に多数のディスクを使用するには、RAIDが必要です。 これには2つの理由がありました。 まず、複数のディスクを一度に1つのファイルシステムに結合する場合、多数のディスクの1つが故障した結果、ファイルシステム全体が失われる危険がありました。 2番目：ディスクの数が増えると、障害の可能性が高まりました。 RAIDが必要だったため、ファイルシステムの一部としてRAIDを実装することにしました。

以前の既存のファイルシステムはRAID上で動作し、物理レベルでのデータの割り当て方法について何も知らなかったため、この情報に基づいて作業を最適化できませんでした。 多くの物理ディスク上のデータの場所のすべての機能を知っている独自のファイルシステムを構築し、RAIDを個別に実装して、作業を可能な限り最適化することができました。
そのため、これらすべてを検討した結果、デバイス用に独自のファイルシステムを作成することにしました。」

（誰が「ブラックジャックと売春婦で」と言ったのですか？;）

WAFLファイルシステムの機能の根底にある主要な原則は、それを既存のすべてのファイルシステムと区別するため、少し矛盾しているように見えるかもしれません。つまり、ファイル内の記録データブロックがその後上書きされません。 削除（クリア）のみできますが、更新はできません。
したがって、ファイルシステム上のデータのブロックは「空」になり、書き込みまたは「書き込み」が可能になります。その後、上位構造のレコードがそれを参照しなくなったら、読み取りまたは削除できます。 ファイルシステムの内部ロジックによれば、すでにデータで占有されているブロックへの書き込み（上書き）はできません。
記録されたファイルの内容に必要な変更は、ファイルシステムの空き領域に「追加」されます。

手順を検討してください。
最初のステップでは、ファイルシステム上の3つのブロック（A、B、およびC）を占めるファイルを確認します。
ステップ2.このファイルを使用するプログラムは、ブロックBに保存されている中間のデータを変更します。書き込み用にファイルを開くと、このデータが変更されますが、FSは、既に記録されたブロックBのデータを変更する代わりに、空きブロック領域の完全に空のブロックに書き込みます。
ステップ3.ファイルシステムは、ファイルが使用するブロックのポインターを、ブロックBから記録されたブロックB 'にシフトします。ブロックBを参照しているユーザーがいないため、ブロックBは解放されて空になります。

このような特異なモデルにより、次の2つの重要な機能を使用できます。

• ランダムストレージエントリをシーケンシャルエントリに変換します。
• ディスク上のデータの状態のいわゆるスナップショット、スナップショット、またはインスタント「スナップショット」を整理することは非常に簡単で効果的です。

これらのポイントをさらに詳しく調べてみましょう。

WAFLファイルシステムブロックの組織構造は、iノードファイルシステム、バークレーのFFSのすべてのUNIX継承者に精通している人なら誰でも理解できるでしょう。
ファイルデータのブロックは、「inode」と呼ばれる構造を使用してアドレス指定されます。
iノードは、直接ファイルデータのブロックと、「ルート」が「ルートiノード」である一種の「ツリー」を形成する「間接アドレス指定」の中間iノードと、ブランチの最後にある直接データのブロックの両方を指すことができます。



ほとんどのUnixファイルシステムはこのスキームを使用していますが、WAFLの新機能は何ですか？

前述したように、すでに記録されているファイルシステムデータの内容は変わらず、新しいブロックは「ツリー」に追加されるだけで（少なくとも誰かがそれらを参照するまでそこにとどまります）、そのような「ルート」を保存することは明らかですツリー、ルートiノード、ある時点で、その時点でディスク上のすべてのデータの完全な「スナップショット」が得られます。 結局、（たとえば、ファイルの以前のコンテンツで）すでに記録されているブロックのコンテンツは、変更されないことが保証されています。
ルートiノードを含む唯一のブロックを保存することにより、それが何らかの方法で参照するすべてのデータも保存します。
これにより、ディスク上のデータ状態のスナップショットを簡単に作成できます。
このような「スナップショット」は、特定の時点（ルートiノードが保存された時点）でのファイルシステム全体の完全なコンテンツのように見えます。 その上の各ファイルは読み取り可能です（もちろん、変更しても機能しません）。

さらに詳しく考えてみましょう。 最初のステップでは、ファイルシステムの3つのブロックにまたがるファイルがあります。
ステップ2では、スナップショットを作成します。 前述のように、これはファイルが占有しているブロックへのアクティブなファイルシステムリンクの単なるコピーです。 これで、ブロックA、B、Cのそれぞれに2つのリンクがあります。 File1からの1つ、スナップショットからのこのファイルからの2番目。 これは、UNIXファイルシステムのリンクに似ていますが、リンクはファイルにつながるのではなく、ファイルシステム上のこのファイルのデータブロックにつながります。 プログラムは、ファイルのブロックBのデータを変更し、代わりに新しいコンテンツがブロックBに書き込まれます。
ステップ3.ただし、古いブロックBは空にならないため、スナップショットから参照されます。 これで、変更前にFile1の内容を読み取りたい場合、file〜snap / File1を使用して、ブロックA、B、Cにアクセスできます。また、File1自体-A、B '、Cを読み取るときに新しいコンテンツを使用できます。スナップショットによる古いものと、ファイルシステムの新しい内容の両方。

上記で述べたように、ファイルシステムに記録するこのような組織により、システムの観点からいくつかの重要なことを実現できます。

• ランダム書き込み操作をストレージシステムのはるかに高速で効率的な順次書き込み操作に変更します（異なるFSの場所にある異なるファイルに論理的に割り当てられたキャッシュエントリのグループ全体を、空のブロックの連続したセグメントに書き込むことができるため）。
• ディスクへの効率的な記録、「フルストライプ」。

NetAppシステムでは珍しいことは、彼らがファイルシステムに実装したものであり、それ自体がRAIDおよびボリュームマネージャーであり、RAIDの珍しいタイプであるRAIDタイプ4であることを思い出します。これは、「パリティ付きストライピング」モデルであり、通常のRAID-5と似ていますが、パリティディスクは別の物理ディスクに割り当てられます（タイプ5のようにRAID全体に「スミア」されません）。

通常、RAID-4には「ワイルド」が使用されるため、めったに使用されませんが、非常に重大な欠点があります-通常使用される場合のパフォーマンスはパリティディスクのパフォーマンスに依存し、RAIDグループへの書き込み操作ごとに変更操作がありますつまり、パリティディスクでは、RAIDグループのサイズをどのように増やしても、その合計パフォーマンスは記録用の1つのディスクのパフォーマンスに達します。
一方、RAID-4は、専用パリティ付きのRAID（たとえば、「非専用パリティ」付きのRAID-5とは異なります）には非常に堅実なプラスがあり、ドライブを「瞬時に」追加することでRAIDの容量を拡張できます。 ディスクをRAID-4に追加しても「RAIDの再構築」は必要ありません。HDDを物理的に挿入し、既存のRAIDにデータディスクを追加した直後に、内部WAFLファイルシステムとその上にあるファイルシステムの両方を拡張することで書き込みを開始できますCIFS、NFS、LUNデータボリュームなどの構造。 当初は保守の容易さを重視していたデバイスと、顧客である非IT企業にとって、これは大きなプラスでした。
しかし、速度をどうするか？

RAID-4に連続して「フルRAIDストリップ」で書き込む場合、パリティディスクに隣接しても問題はないことがわかりました。 準備されたストライプは、1回の書き込み操作ですべてのRAIDグループディスクに記録されます。次に、次のストライプがアセンブルされることを予期し、一度に書き込みます。

どのファイルシステムでも何ができないのですか？
「ランダム」レコード。 最新のタスクに関する記録の大部分は、ディスクスペース上のかなり混oticとした記録です。 古典的なファイルシステムでは、ディスクスペース全体にランダムに散らばった数千、数万のデータブロックを上書きせざるを得ないため、通常、ディスクの観点からロジックがないため、キャッシュに「フルストリップ」を収集することは非常に困難になります。 これを行うには、キャッシュの書き込みスペースを増やすか、データがキャッシュ内にある時間を長くする必要があります。これにより、最終的に、この「パズル」で必要なストリップを収集し、できるだけ効率的にリセットできる可能性が高くなりますRAIDで。

ただし、ご存知のとおり、WAFLでは、ファイルの途中のいくつかの（キロ）バイトを上書きするためにドライブヘッドの「パンケーキ」を駆動する必要はありません。 データを変更する必要がありますか？ 問題ありません。 ここには大きな空のセグメントがあり、そこに蓄積されたすべてのものを一度に書き込み、iノードのポインターを新しい場所に再配置します。 記録キューを一度に待機しているバイトグループ全体が、パンケーキを頭で追いかけることなく、一度に（順次）ディスクにリークします。 記録が完了し、以前にストライプに対して計算されたパリティ値も一度にパリティディスクに記録されます。

もちろん、何も提供されず、ランダムレコードをシーケンシャルレコードに変換すると、「シーケンシャル」読み取り値を「ランダム」レコードに変換できる場合があります。 ただし、実際には、実際には連続した読み取り値（および連続したレコード）はそれほど多くないことが示されており、ファイルシステム内のファイルの「スミアリング」は、比較的ランダムな読み取り値には比較的ほとんど影響しません。
さらに、大規模な読み取りキャッシュは、ほとんどの場合、この問題にうまく対処します。
SEQUENTIAL読み取りのパフォーマンスが非常に重要な場合（たとえば、主にファイル内で順次発生するバックアップ時）、NetAppシステムには特別なバックグラウンド最適化プロセスがあり、データ配置の「シーケンス」の度合いを継続的に増加します（UNIX FSなど） 「連続」と呼ばれます）、より長い連続した「チャンク」で連続的に収集されたと評価されたデータで、さらに連続した読み取りを容易にします （順次読み取り）。

WAFLの2番目の機能は、異常な「ロギング」スキームです。 1993年、WAFLが登場したとき、ジャーナリングはファイルシステムではまだかなり珍しい機能でした。WAFLを作成するときのタスクの1つは、データの一貫したストレージを整理し、障害後にすばやく再起動することでした。 これらの年の間に、UNIXサーバー上の大規模ファイルシステムの「ダーティな」再起動により、fsckが数分、場合によっては数時間も開始されることがよくありました。

WAFLは、「ジャーナル」が別の物理デバイス（NVRAM）でレンダリングされる、やや珍しいスキームを使用します。



NVRAMは珍しいデバイスです。 外見は、RAMと電源を切ったシステムの電源を入れてデータを保存するバッテリーを備えた、今日おなじみのキャッシングコントローラーによく似ていますが、その動作原理はまったく異なります。

ストレージシステムに送信されるデータとコマンド（NFS操作など）はNVRAMに事前に蓄積され、その後、ディスクに「原子的に」転送され、いわゆる整合点（CP）、「整合点」、および「整合状態」を作成しますCPはそのような特別な内部「スナップショット」でもあり、同じ論理メカニズムが使用されます）。 CPを作成する操作は、数秒ごとに発生するか、一定量のメモリがNVRAM（最高水準点）でいっぱいになったときに発生します。 CP間では、ファイルシステムの状態は完全に一貫しており、次のCPへの切り替えは瞬時かつアトミックであるため、ファイルシステムは常に全体的な状態になります。これはSQLデータベースの編成方法に似ています。

システムの観点から見ると、データは完全に正常に記録されているか、まだNVRAMを離れておらず、ディスクに到達していません。 ファイルシステムはディスク上のコンテンツを上書きしないため、「アトミック性」を整理するのは非常に簡単です。データが一部のブロックで既に変更されており、まだソフトウェア（ハードウェア障害など）が発生していない状況は、単に不可能です。 EMPTYと見なされるブロックの一部は、新しいデータで既に満たされている可能性がありますが、「ポインター」がファイルシステムの新しい状態を修正する新しいCP（インスタントアクション）に移動されるまで、以前のCPの一貫した状態のままになり、これは大した問題ではありません。 システムが操作可能な状態に復元された場合、記録は最後に成功したCPで中断された瞬間から続行され、NVRAMにあるデータをバッテリー電源で（システム全体に電力が供給されない状態で最大1週間）、プロセスが中断されたデータを書き留めてから、CPを再配置します。 障害発生時の「半記録」データは、CPへのポインターが更新されるまで「空」と見なされる「FSレベル」であり（NVRAM内のデータは残されません）。
つまり、システムの動作は次のとおりです。

NVRAM-システム：CPを書く時が来ました！
システム-NVRAM：さあ、行きましょう。
書いています。
NVRAMシステム：お元気ですか？ すべて準備ができていますか？
NVRAM：完了、シェフ！
システム-ファイルシステム：まあ、神と共に！ プリサディン！
ファイルシステム：（生成されたCPへの現在の状態のポインターをインクリメント）oink！

記録失敗オプション：
NVRAM-システム：すべてがなくなった、シェフ！ ディスクが応答しない！ シェフ？ ここにいますか
システム（起動）：ええ、それは何でしたか？ NVRAM！ フリーズ ファイルシステム-どこにも行きません！ 失敗する前に最後の有効なCPエントリを使用します！ NVRAM-最初から中断された最後の記録操作を繰り返すようになりました！
NVRAM：はい、チーフ！

この独創的なスキームにより、ファイルシステムは非常に一貫性があり安定しています。これにより、NetAppシステムの多くの実際の管理者は、その整合性に違反するケースや「chkdsk（近隣のOSギャラクシーの居住者向けのfsck ）」。
かっこ内では、もちろん、システム内のWAFL整合性コントロールが必要な場合に注意してください。

1994年にUSENIXジャーナルで発行されたWAFL構築の基本原理を説明する著者の出版物「NFSファイルサーバー用の特殊なファイルシステムの作成」から、WAFLデバイスと動作原理の詳細を読むことができます。 Netwellのロシア販売代理店のWebサイトで、定期的に更新される翻訳されたベストプラクティスのライブラリで、このドキュメントの翻訳をダウンロードできます 。

次の記事では、ストレージシステムの速度を低下させないデータ重複排除をWAFLがどのように実装したかについて説明します。