この春、私たちはすでにいくつかの入門的なトピックについて説明しました。たとえば、 ドライブの速度を確認する方法 и RAIDとは何ですか。 そのうちの XNUMX つ目では、ZFS におけるさまざまなマルチディスク トポロジのパフォーマンスの研究を続けることさえ約束しました。 これは、現在どこでも実装されている次世代ファイル システムです。 Apple до Ubuntu.

さて、好奇心旺盛な読者の皆さん、今日は ZFS について知るのに最適な日です。 OpenZFS 開発者 Matt Ahrens の謙虚な意見としては、「それは本当に難しい」ということだけは知っておいてください。

しかし、XNUMX ディスク ZFS 構成のすべてのオプションの数字に到達する前に、そして必ずそうなると約束します。 方法 一般に、ZFS はデータをディスクに保存します。

Zpool、vdev、デバイス

この完全なプール図には、各クラスに 2 つずつ、RAIDzXNUMX 用に XNUMX つずつ、合計 XNUMX つの補助 vdev が含まれています。

通常、不一致の vdev タイプとサイズのプールを作成する理由はありませんが、必要に応じて作成することを妨げるものはありません。

ZFS ファイルシステムを本当に理解するには、その実際の構造を詳しく見る必要があります。 まず、ZFS は、従来のレベルのボリュームおよびファイル システム管理を統合します。 XNUMX 番目に、トランザクションのコピーオンライト メカニズムを使用します。 これらの機能は、システムが従来のファイル システムや RAID アレイとは構造的に大きく異なることを意味します。 理解すべき基本的な構成要素の最初のセットは、ストレージ プール (zpool)、仮想デバイス (vdev)、および実デバイス (device) です。

zpool

zpool ストレージ プールは、最上位の ZFS 構造です。 各プールには XNUMX つ以上の仮想デバイスが含まれます。 さらに、それらのそれぞれには XNUMX つ以上の実デバイス (デバイス) が含まれています。 仮想プールは自己完結型のブロックです。 XNUMX 台の物理コンピューターに XNUMX つ以上の個別のプールを含めることができますが、それぞれは他のプールから完全に独立しています。 プールは仮想デバイスを共有できません。

ZFS の冗長性は、プール レベルではなく、仮想デバイス レベルです。 プール レベルでは冗長性はまったくありません。ドライブ vdev または特殊な vdev が失われると、それとともにプール全体も失われます。

最新のストレージ プールは、キャッシュや仮想デバイス ログが失われても生き残ることができますが、停電やシステム クラッシュ中に vdev ログが失われた場合には、少量のダーティ データが失われる可能性があります。

ZFS の「データ ストライプ」はプール全体に書き込まれるという誤解がよくあります。 本当じゃない。 Zpool は全然面白くない RAID0、むしろ面白い JBOD 複雑な変数分配メカニズムを備えています。

ほとんどの場合、エントリは利用可能な空き領域に応じて利用可能な仮想デバイスに分散されるため、理論上はすべて同時に埋められます。 ZFS の新しいバージョンでは、現在の vdev の使用状況 (使用率) が考慮されます。ある仮想デバイスが別の仮想デバイスよりも大幅にビジーな場合 (たとえば、読み取り負荷により)、空き容量が最も多いにもかかわらず、一時的に書き込みがスキップされます。スペース比率。

最新の ZFS 書き込み割り当て方法に組み込まれた使用率検出メカニズムは、異常に高負荷の期間中のレイテンシーを削減し、スループットを向上させることができますが、そうではありません。 真っ白なカルテ XNUMX つのプール内で低速 HDD と高速 SSD が意図せず混在することについて。 このような不均等なプールは、依然として最も遅いデバイスの速度で動作します。つまり、プール全体がそのようなデバイスで構成されているかのように動作します。

vdev

各ストレージ プールは、1 つ以上の仮想デバイス (仮想デバイス、vdev) で構成されます。 さらに、各 vdev には 2 つ以上の実デバイスが含まれます。 ほとんどの仮想デバイスは単純なデータ ストレージに使用されますが、CACHE、LOG、SPECIAL などの vdev ヘルパー クラスがいくつかあります。 これらの vdev タイプのそれぞれは、単一デバイス (単一デバイス)、RAIDz3、RAIDzXNUMX、RAIDzXNUMX、またはミラー (ミラー) の XNUMX つのトポロジのいずれかを持つことができます。

RAIDz1、RAIDz2、および RAIDz3 は、昔からダブル (対角) パリティ RAID と呼ばれていたものの特別な種類です。 1、2、および 3 は、各データ ストリップに割り当てられるパリティ ブロックの数を示します。 パリティ用に個別のディスクを使用する代わりに、RAIDz 仮想デバイスはこのパリティをディスク全体にほぼ均等に分散します。 RAIDz アレイでは、パリティ ブロックと同数のディスクが失われる可能性があります。 もう XNUMX つを失うとクラッシュし、ストレージ プールも一緒に奪われます。

ミラーリングされた仮想デバイス (ミラー vdev) では、各ブロックは vdev 内の各デバイスに保存されます。 XNUMX 幅のミラーが最も一般的ですが、任意の数のデバイスをミラー内に含めることができます。読み取りパフォーマンスとフォールト トレランスを向上させるために、大規模なインストールではトリプルがよく使用されます。 vdev 内の少なくとも XNUMX つのデバイスが機能し続ける限り、vdev ミラーは障害が発生しても存続できます。

単一の vdev は本質的に危険です。 このような仮想デバイスは一度障害が発生すると存続できません。また、ストレージまたは特殊な vdev として使用されている場合、その障害はプール全体の破壊につながります。 ここは非常に注意してください。

CACHE、LOG、および SPECIAL VA は、上記のトポロジのいずれかを使用して作成できますが、SPECIAL VA の損失はプールの損失を意味するため、冗長トポロジを強くお勧めします。

デバイス

これはおそらく ZFS で最も理解しやすい用語です。文字通り、ブロック ランダム アクセス デバイスです。 仮想デバイスは個々のデバイスで構成されているのに対し、プールは仮想デバイスで構成されていることに注意してください。

磁気ディスクまたはソリッド ステートのディスクは、vdev の構成要素として使用される最も一般的なブロック デバイスです。 ただし、/dev に記述子を持つデバイスはどれでも使用できるため、ハードウェア RAID アレイ全体を個別のデバイスとして使用できます。

シンプルな RAW ファイルは、vdev を構築するための最も重要な代替ブロック デバイスの XNUMX つです。 からのテストプール スパースファイル これは、プール コマンドをチェックし、特定のトポロジのプールまたは仮想デバイスで利用可能なスペースの量を確認するのに非常に便利な方法です。

わずか数秒でスパース ファイルからテスト プールを作成できますが、その後、プール全体とそのコンポーネントを削除することを忘れないでください。

サーバーを 10 つのディスク上に配置し、9300 TB ディスク (約 2 GiB) を使用する予定であるとします。しかし、どのトポロジがニーズに最適であるかわかりません。 上の例では、スパース ファイルからテスト プールを数秒で構築しています。これで、10 台の 50 TB ディスクからなる RAIDzXNUMX vdev が XNUMX TiB の使用可能な容量を提供することがわかりました。

もう XNUMX つの特別なクラスのデバイスは SPARE (スペア) です。 ホットスワップ デバイスは、通常のデバイスとは異なり、単一の仮想デバイスではなく、プール全体に属します。 プール内の vdev に障害が発生し、スペア デバイスがプールに接続されて使用可能な場合、そのデバイスは影響を受ける vdev に自動的に参加します。

影響を受ける vdev に接続した後、スペア デバイスは、失われたデバイス上にあるはずのデータのコピーまたは再構築の受信を開始します。 従来の RAID ではこれを再構築と呼びますが、ZFS では再同期化と呼びます。

スペア デバイスは故障したデバイスを永久に置き換えるものではないことに注意することが重要です。 これは、vdev の機能が低下する時間を短縮するための一時的な置き換えにすぎません。 管理者が障害が発生した vdev を交換すると、その永続デバイスに冗長性が復元され、SPARE が vdev から切断され、プール全体のスペアとして動作するように戻ります。

データセット、ブロック、セクター

ZFS の取り組みで理解すべき次の構成要素は、ハードウェアについてではなく、データ自体がどのように編成され、保存されるかについてです。 全体的な構造の理解を維持しながら詳細が乱雑にならないように、ここではメタスラブなどのいくつかのレベルをスキップしています。

データセット (データセット)

最初にデータセットを作成すると、利用可能なすべてのプール スペースが表示されます。 次に、クォータを設定し、マウント ポイントを変更します。 魔法！

Zvol の大部分は、ファイルシステム層を取り除いた単なるデータセットですが、ここでは完全に通常の ext4 ファイルシステムに置き換えています。

ZFS データセットは、標準のマウントされたファイル システムとほぼ同じです。 通常のファイルシステムと同様、一見すると「ただのフォルダー」に見えます。 ただし、通常のマウント可能なファイルシステムと同様に、各 ZFS データセットには独自の基本プロパティのセットがあります。

まず第一に、データセットには割り当てを割り当てることができます。 設定されている場合 zfs set quota=100G poolname/datasetnameそうすると、マウントされたフォルダーに書き込むことができなくなります。 /poolname/datasetname 100 GiB を超える。

各行の先頭にスラッシュが存在するか存在しないことに注意してください。 各データセットは、ZFS 階層とシステム マウント階層の両方に独自の場所を持ちます。 ZFS 階層には先頭にスラッシュがありません。最初にプール名を入力し、次にあるデータセットから次のデータセットへのパスを入力します。 例えば、 pool/parent/child という名前のデータセットの場合 child 親データセットの下にある parent クリエイティブ名の付いたプール内 pool.

デフォルトでは、データセットのマウント ポイントは、先頭にスラッシュが付いた ZFS 階層内の名前と同等になります (プールという名前)。 pool としてマウントされる /pool、データセット parent に取り付けられている /pool/parent、および子データセット child に取り付けられている /pool/parent/child。 ただし、データセットのシステム マウント ポイントは変更できます。

指定すると zfs set mountpoint=/lol pool/parent/child、次にデータセット pool/parent/child システムに次のようにマウントされます /lol.

データセットに加えて、ボリューム (zvol) についても言及する必要があります。 ボリュームはデータセットとほぼ同じですが、実際にはファイル システムを持たず、単なるブロック デバイスである点が異なります。 たとえば、次のように作成できます。 zvol 名前で mypool/myzvol次に、ext4 ファイル システムでフォーマットし、そのファイル システムをマウントします。これで、ext4 ファイル システムが完成しましたが、ZFS のすべてのセキュリティ機能が備えられています。 これは単一マシンではばかげているように思えるかもしれませんが、iSCSI デバイスをエクスポートするときのバックエンドとしてははるかに理にかなっています。

ブロック

ファイルは XNUMX つ以上のブロックで表されます。 各ブロックは XNUMX つの仮想デバイスに保存されます。 通常、ブロック サイズはパラメータと同じです。 レコードサイズ、ただし、次のように減らすことができます。 2^シフトメタデータまたは小さなファイルが含まれている場合。

私たちは本当に 本当に 小さすぎるシフトを設定すると、パフォーマンスが大幅に低下するというのは冗談ではありません。

ZFS プールでは、メタデータを含むすべてのデータがブロックに保存されます。 各データセットの最大ブロックサイズはプロパティで定義されます。 recordsize (レコードサイズ)。 レコード サイズは変更できますが、データセットに既に書き込まれているブロックのサイズや位置は変更されません。新しいブロックが書き込まれるときにのみ影響します。

特に指定がない限り、現在のデフォルトのレコード サイズは 128 KiB です。 パフォーマンスが完璧ではない場合、これは一種のトリッキーなトレードオフですが、ほとんどの場合、それほどひどいことではありません。 Recordsize 4K から 1M までの任意の値に設定できます (詳細設定あり) recordsize さらに多くインストールすることもできますが、これが良い考えになることはほとんどありません)。

どのブロックも 2 つのファイルのデータのみを参照します。4 つの異なるファイルを XNUMX つのブロックに詰め込むことはできません。 各ファイルは、サイズに応じて XNUMX つ以上のブロックで構成されます。 ファイル サイズがレコード サイズより小さい場合、ファイルはより小さいブロック サイズで保存されます。たとえば、XNUMX KiB ファイルのブロックは、ディスク上の XNUMX KiB セクターを XNUMX つだけ占有します。

ファイルが十分に大きく、いくつかのブロックが必要な場合、このファイルのすべてのレコードは次のサイズになります。 recordsize - 最後のエントリを含み、その主要部分は次のとおりである可能性があります。 未使用スペース.

zvols にはプロパティがありません recordsize — 代わりに同等のプロパティを持ちます volblocksize.

セクター

最後の最も基本的な構成要素はセクターです。 これは、基礎となるデバイスに対して書き込みまたは読み取りができる最小の物理単位です。 数十年間、ほとんどのディスクは 512 バイトのセクターを使用していました。 最近では、ほとんどのディスクが 4 KiB セクターに構成されており、一部のディスク (特に SSD) には 8 KiB 以上のセクターがあります。

ZFS システムには、セクター サイズを手動で設定できるプロパティがあります。 この物件 ashift。 少し紛らわしいですが、ashft は XNUMX の累乗です。 例えば、 ashift=9 セクタ サイズが 2^9、つまり 512 バイトであることを意味します。

ZFS は、各ブロックデバイスが新しい vdev に追加されるときにオペレーティングシステムにクエリを実行して、各ブロックデバイスに関する詳細情報を取得し、理論的にはその情報に基づいて ashift を自動的に適切にインストールします。 残念ながら、Windows XP との互換性を維持するために、多くのドライブはセクタ サイズを偽っています (Windows XP は他のセクタ サイズのドライブを認識できませんでした)。

これは、ZFS 管理者がデバイスの実際のセクター サイズを把握し、手動で設定することを強くお勧めすることを意味します。 ashift。 ashift の設定が低すぎると、読み取り/書き込み操作の数が天文学的に増加します。 したがって、512 バイトの「セクタ」を実際の 4 KiB セクタに書き込むということは、最初の「セクタ」を書き込み、次に 4 KiB セクタを読み取り、512 番目の 4 バイトの「セクタ」で変更し、新しいセクタに書き戻す必要があることを意味します。エントリごとに XNUMX KiB セクターなど。

現実の世界では、このようなペナルティは Samsung EVO SSD に課せられます。 ashift=13ただし、これらの SSD はセクター サイズについて嘘をついているため、デフォルトは次のように設定されています。 ashift=9。 経験豊富なシステム管理者がこの設定を変更しない場合、この SSD は機能します。 遅い 従来の磁気HDD。

比較用、サイズが大きすぎる場合 ashift 実質的に罰則はありません。 実際のパフォーマンスの低下はなく、未使用スペースの増加はごくわずかです (圧縮が有効な場合はゼロ)。 したがって、512 バイトのセクターを使用するドライブでも、 ashift=12 あるいは ashift=13自信を持って未来に向かうために。

プロパティ ashift vdev 仮想デバイスごとに設定され、 プール用ではありません、多くの人が誤解しているように、インストール後も変化しません。 うっかりぶつけてしまったら ashift 新しい vdev をプールに追加すると、そのプールが低パフォーマンスのデバイスで取り返しのつかないほど汚染されてしまうため、通常はプールを破棄して最初からやり直す以外に選択肢はありません。 vdev を削除しても、壊れた構成からは救われません ashift!

コピーオンライトメカニズム

通常のファイル システムがデータを上書きする必要がある場合、データが存在する各ブロックを変更します。

コピーオンライト ファイル システムは、新しいブロック バージョンを書き込み、古いバージョンのロックを解除します。

要約すると、ブロックの実際の物理的な位置を無視すると、「データ彗星」は、利用可能なスペースのマップ上を左から右に移動する「データ ワーム」に単純化されます。

これで、コピーオンライト スナップショットがどのように機能するかについてよく理解できるようになりました。各ブロックは複数のスナップショットに属することができ、関連付けられたすべてのスナップショットが破棄されるまで保持されます。

Copy on Write (CoW) メカニズムは、ZFS をこれほど素晴らしいシステムにする基本的な基盤です。 基本的な概念は単純です。従来のファイル システムにファイルの変更を要求すると、要求されたとおりに実行されます。 コピーオンライト ファイル システムに同じことを要求すると、「OK」とは言いますが、嘘をつきます。

代わりに、コピーオンライト ファイル システムは、変更されたブロックの新しいバージョンを書き込み、ファイルのメタデータを更新して古いブロックのリンクを解除し、書き込んだばかりの新しいブロックを関連付けます。

古いブロックの切り離しと新しいブロックのリンクは XNUMX 回の操作で行われるため、中断することはできません。これが起こった後に電源を切ると、ファイルの新しいバージョンが作成され、早めに電源を切ると、古いバージョンが保持されます。 。 いずれの場合も、ファイル システム内で競合は発生しません。

ZFS のコピーオンライトは、ファイル システム レベルだけでなく、ディスク管理レベルでも発生します。 これは、ZFS が空白文字の影響を受けないことを意味します (RAID の穴) - システムがクラッシュし、再起動後にアレイが損傷する前に、ストリップが部分的にしか記録できなかった現象。 ここではストライプはアトミックに書き込まれ、vdev は常にシーケンシャルであり、 ボブはあなたの叔父です.

ZIL: ZFS インテント ログ

ZFS システムは同期書き込みを特別な方法で扱います。同期書き込みは一時的ではありますがすぐに ZIL に保存され、後で非同期書き込みとともに永続的に書き込まれます。

通常、ZIL に書き込まれたデータは再度読み取られることはありません。 ただし、システムクラッシュの後は可能性があります

SLOG (セカンダリ LOG デバイス) は、ZIL をメイン ストレージとは別に保存できる特殊な (できれば非常に高速な) vdev です。

クラッシュ後、ZIL 内のすべてのダーティ データが再生されます。この場合、ZIL は SLOG 上にあるため、そこから再生されます。

書き込み操作には、同期 (sync) と非同期 (async) の XNUMX つの主なカテゴリがあります。 ほとんどのワークロードでは、書き込みの大部分が非同期です。ファイル システムにより、書き込みを集約してバッチで発行できるため、断片化が軽減され、スループットが大幅に向上します。

同期録音はまったく別の問題です。 アプリケーションが同期書き込みをリクエストすると、ファイル システムに次のように指示します。「これを不揮発性メモリにコミットする必要があります」 今すぐそれまでは、他にできることは何もありません。」 したがって、同期書き込みはすぐにディスクにコミットされる必要がありますが、それによって断片化が増加したり、スループットが低下したりする場合は、それは問題ありません。

ZFS は、同期書き込みを通常のファイル システムとは異なる方法で処理します。同期書き込みを通常のストレージに即座にコミットするのではなく、ZFS インテント ログ (ZIL) と呼ばれる特別なストレージ領域にコミットします。 重要なのは、これらのレコードが また メモリ内に残り、通常の非同期書き込みリクエストとともに集約され、後で完全に通常の TXG (トランザクション グループ) としてストレージにフラッシュされます。

通常の動作では、ZIL は書き込まれ、再度読み取られることはありません。 しばらくして、ZIL からのレコードが RAM から通常の TXG 内のメイン ストレージにコミットされると、それらのレコードは ZIL から切り離されます。 ZIL から何かが読み取られるのは、プールがインポートされたときのみです。

ZIL 内にデータがあるときに ZFS に障害が発生した場合 (オペレーティング システムのクラッシュや停電など)、そのデータは次回のプールのインポート中 (たとえば、緊急システムの再起動時) に読み取られます。 ZIL 内のすべてのものが読み取られ、TXG にグループ化され、メイン ストレージにコミットされた後、インポート プロセス中に ZIL から切り離されます。

vdev ヘルパー クラスの XNUMX つは、LOG または SLOG (LOG のセカンダリ デバイス) と呼ばれます。 これには XNUMX つの目的があります。それは、ZIL をメインの vdev ストアに保存するのではなく、ZIL を保存するための別の、できれば高速で書き込み耐性の高い vdev をプールに提供することです。 ZIL 自体は、格納場所に関係なく同じように動作しますが、LOG vdev の書き込みパフォーマンスが非常に高い場合は、同期書き込みが高速になります。

LOG を含む vdev をプールに追加しても機能しない できない 非同期書き込みパフォーマンスを向上させる - たとえすべての書き込みを ZIL に強制したとしても zfs set sync=always、ログがない場合と同じ方法および同じペースで TXG のメイン ストレージにリンクされます。 唯一の直接的なパフォーマンスの向上は、同期書き込みのレイテンシーです (ログが高速になると操作が高速化されるため)。 sync).

ただし、すでに大量の同期書き込みが必要な環境では、vdev LOG は非同期書き込みと非キャッシュ読み取りを間接的に高速化できます。 ZIL エントリを別の vdev LOG にオフロードすると、プライマリ ストレージ上の IOPS の競合が減り、すべての読み取りと書き込みのパフォーマンスがある程度向上します。

スナップショット

コピーオンライト メカニズムは、ZFS アトミック スナップショットと増分非同期レプリケーションに必要な基盤でもあります。 アクティブなファイル システムには、すべてのレコードに現在のデータをマークするポインタ ツリーがあります。スナップショットを作成するときは、このポインタ ツリーのコピーを作成するだけです。

アクティブなファイルシステムでレコードが上書きされると、ZFS は最初に新しいブロックバージョンを未使用のスペースに書き込みます。 次に、古いバージョンのブロックを現在のファイル システムから切り離します。 ただし、スナップショットが古いブロックを参照している場合、そのブロックは変更されないままになります。 古いブロックは、このブロックを参照しているすべてのスナップショットが破棄されるまで、実際には空き領域として復元されません。

複製

2015 年の私の Steam ライブラリは 158 GiB で、126 個のファイルが含まれていました。 これは rsync にとって最適な状況にかなり近く、ネットワーク上の ZFS レプリケーションは「わずか」 927% 高速でした。

同じネットワーク上で、単一の 40 GB Windows 7 仮想マシン イメージ ファイルをレプリケートする場合は、まったく別の話になります。 ZFS レプリケーションは rsync より 289 倍高速です。 --inplace で rsync を呼び出すことができるほど精通している場合は、「わずか」 161 倍高速です。

VM イメージがスケーリングされると、rsync はそれに合わせてスケーリングを発行します。 1,9 TiB は、最新の VM イメージとしてはそれほど大きくありませんが、rsync の --inplace 引数を使用した場合でも、ZFS レプリケーションが rsync よりも 1148 倍高速になるには十分な大きさです

スナップショットの仕組みを理解すれば、レプリケーションの本質を簡単に理解できるはずです。 スナップショットはレコードへのポインタのツリーにすぎないため、次のようにすると次のようになります。 zfs send スナップショットを作成した後、このツリーとそれに関連付けられたすべてのレコードの両方を送信します。 これを送信するとき zfs send в zfs receive ターゲット上では、ブロックの実際の内容と、ブロックを参照するポインターのツリーの両方がターゲット データセットに書き込まれます。

XNUMX番目ではさらに面白くなります zfs send。 現在、XNUMX つのシステムがあり、それぞれに以下が含まれています。 poolname/datasetname@1そして、新しいスナップショットを撮ります poolname/datasetname@2。 したがって、元のプールには datasetname@1 и datasetname@2、ターゲット プールにはこれまでのところ最初のスナップショットのみが含まれています datasetname@1.

ソースとターゲットの間に共通のスナップショットがあるため、 datasetname@1、私たちにはできます 増分 zfs send その上。 システムに対してこう言うと、 zfs send -i poolname/datasetname@1 poolname/datasetname@2、XNUMX つのポインター ツリーを比較します。 にのみ存在するポインタ @2、明らかに新しいブロックを参照しているため、これらのブロックの内容が必要です。

リモート システムで増分を処理する send 同様にシンプルです。 まず、ストリームに含まれるすべての新しいエントリを書き込みます send、そしてそれらのブロックへのポインターを追加します。 ほら、できましたよ @2 新システムで！

ZFS の非同期増分レプリケーションは、rsync などの以前の非スナップショットベースの方法に比べて大幅に改善されています。 どちらの場合も、変更されたデータのみが転送されますが、最初に rsync を実行する必要があります。 読む ディスクから両面のすべてのデータを取り出して合計を確認し、比較します。 対照的に、ZFS レプリケーションはポインター ツリーと共有スナップショットに存在しないブロックのみを読み取ります。

内蔵圧縮機能

コピーオンライト メカニズムにより、インライン圧縮システムも簡素化されます。 従来のファイル システムでは、圧縮に問題があります。変更されたデータの古いバージョンと新しいバージョンの両方が同じスペースに存在します。

ファイルの途中にあるデータが 0x00000000 などから始まるメガバイトのゼロであると考えると、それをディスク上の 256 セクターに圧縮するのは非常に簡単です。 しかし、そのメガバイトのゼロを、JPEG や疑似ランダム ノイズなどの非圧縮データのメガバイトに置き換えるとどうなるでしょうか? 予想外なことに、このメガバイトのデータには 4 つではなく XNUMX 個の XNUMX KiB セクターが必要ですが、ディスク上のこの場所には XNUMX つのセクターだけが予約されています。

ZFS では、変更されたレコードは常に未使用のスペースに書き込まれるため、この問題は発生しません。元のブロックは 4 KiB セクターを 256 つだけ占有し、新しいレコードは XNUMX セクターを占有しますが、これは問題ではありません。「」から最近変更されたフラグメントです。ファイルの「middle」は、サイズが変更されたかどうかに関係なく、未使用の領域に書き込まれるため、ZFS ではこれは非常に一般的な状況です。

ネイティブ ZFS 圧縮はデフォルトで無効になっており、システムはプラグ可能なアルゴリズム (現在は LZ4、gzip (1-9)、LZJB、および ZLE) を提供しています。

• LZ4 は、非常に高速な圧縮と解凍を提供し、ほとんどのユースケース (かなり遅い CPU 上でも) でパフォーマンス上の利点を提供するストリーミング アルゴリズムです。
• GZIP は、すべての Unix ユーザーが知っており、愛用している由緒あるアルゴリズムです。 圧縮レベル 1 ～ 9 で実装でき、レベル 9 に近づくにつれて圧縮率と CPU 使用率が増加します。このアルゴリズムはすべてのテキスト (またはその他の高圧縮性) の使用例に適していますが、それ以外の場合は CPU の問題が頻繁に発生します。このアルゴリズムを使用してください。特に高いレベルでは注意してください。
• LZJB ZFS の独自のアルゴリズムです。 これは時代遅れであり、もう使用すべきではありません。LZ4 はあらゆる点でそれを上回っています。
• ひどく - ゼロレベルエンコーディング、ゼロレベルエンコーディング。 通常のデータにはまったく影響しませんが、大きなゼロのシーケンスが圧縮されます。 非圧縮データは無視されますが、結果のレコード内の未使用スペースが圧縮されるため、完全に非圧縮のデータセット (JPEG、MP4、またはその他の既に圧縮された形式など) に役立ちます。

ほぼすべてのユースケースに LZ4 圧縮をお勧めします。 非圧縮データに遭遇した場合のパフォーマンスの低下は非常に小さいです。 インクリメント 一般的なデータのパフォーマンスは重要です。 Windows オペレーティング システムの新規インストール用の仮想マシン イメージ (新しくインストールされた OS、まだ内部にデータがない) をコピーする compression=lz4 よりも 27% 早く合格 compression=noneで 2015年のこのテスト.

ARC - 適応型置換キャッシュ

ZFS は、最近読み取られたブロックのコピーを RAM に保存するためにオペレーティング システムのページ キャッシュに依存するのではなく、独自の読み取りキャッシュ メカニズムを使用する、私たちが知る限り唯一の最新のファイル システムです。

ネイティブ キャッシュにも問題がないわけではありませんが、ZFS はカーネルほど早く新しいメモリ割り当て要求に応答できないため、新たな課題が発生します。 malloc() ARC が現在占有している RAM が必要な場合、メモリ割り当てが失敗する可能性があります。 しかし、少なくとも現時点では、独自のキャッシュを使用する十分な理由があります。

MacOS、Windows、Linux、BSD などの既知の最新のオペレーティング システムはすべて、LRU (Least Recent Used) アルゴリズムを使用してページ キャッシュを実装しています。 これは、読み取りのたびにキャッシュされたブロックを「キューの上」にプッシュし、新しいキャッシュ ミス (キャッシュからではなくディスクから読み取られるべきブロック) を追加するために必要に応じてブロックを「キューの下」にプッシュする原始的なアルゴリズムです。上。

通常、このアルゴリズムは正常に動作しますが、大規模な作業データセットを含むシステムでは、LRU によってスラッシングが発生しやすくなります。つまり、キャッシュから二度と読み取られないブロック用のスペースを確保するために、頻繁に必要なブロックが排除されます。

ARC これは、「重み付けされた」キャッシュと考えることができる、はるかに単純なアルゴリズムではありません。 キャッシュされたブロックが読み取られるたびに、ブロックは少し「重くなり」、削除が難しくなります。ブロックを削除した後でも、 追跡された 一定期間内。 追い出されたが、その後キャッシュに読み戻す必要があるブロックも「重くなり」ます。

これらすべての最終結果は、キャッシュ ヒット (キャッシュから実行される読み取り) とキャッシュ ミス (ディスクからの読み取り) の比率であるヒット率がはるかに高いキャッシュになります。 これは非常に重要な統計です。キャッシュ ヒット自体が桁違いに速く処理されるだけでなく、キャッシュ ヒットが増えるほど同時ディスク リクエストが減り、残りのミスの待ち時間が短くなるため、キャッシュ ミスもより速く処理されます。ディスクと一緒に提供する必要があります。

まとめ

ZFS の基本的なセマンティクス (コピーオンライトの仕組み、ストレージ プール、仮想デバイス、ブロック、セクター、ファイル間の関係) を学習したら、実際のパフォーマンスについて実数を使って議論する準備が整います。

次のパートでは、ミラーリングされた vdev と RAIDz を備えたプールの実際のパフォーマンスを相互に比較し、また、これまで調査してきた従来の Linux カーネル RAID トポロジと比較して見ていきます。 前.

当初は、ZFS トポロジ自体の基本だけを説明したいと考えていましたが、 そのような L2ARC、SLOG、特別な割り当てなどの補助 vdev タイプの使用を含む、ZFS のより高度なセットアップとチューニングについて説明する準備をしましょう。

出所： habr.com