スクラブが遅いなら、ZFS 設計に問題がある

コンテンツへスキップ ホーム リソース 記事 スクラブが遅いなら、ZFS 設計に問題がある スクラブが遅いなら、ZFS 設計に問題がある 2026年7月22日 ZFS のスクラブパフォーマンスは、本番ワークロードを犠牲にするべきではありません。スクラブがレイテンシやダウンタイムを引き起こす場合、お使いのプールには健全なメンテナンスに必要な IOPS とメタデータパフォーマンスが不足しています。スクラブパフォーマンスが低下する理由、プールの設計が問題にどのように寄与するか、そして特別な VDEV によるメタデータオフロードがスクラブとリシルバーのパフォーマンスをどのように向上させるかを学びましょう。 Klara のニュースレターを購読するには、メールアドレスを入力してください。 * 主要記事の要点 ZFS のスクラブパフォーマンスは、プールの健全性を反映します。スクラブが本番環境に顕著な影響を与える場合、それはストレージ設計が日常的なメンテナンスに必要な IOPS とヘッドルームを欠いている兆候です。 プールの設計は容量と同じくらい重要です。高い使用率、断片化されたプール、および幅の広い RAIDZ VDEV はメタデータオーバーヘッドを増加させ、スクラブとリシルバーを著しく遅くします。 特別な VDEV はメンテナンスの影響を軽減します。メタデータ（およびオプションで小さなブロック）をミラーリングされた SSD または NVMe デバイスにオフロードすると、プール全体を再設計することなく、スクラブ、リシルバー、および日常のファイルシステムパフォーマンスが向上します。 Allan Jude ご存知でしたか？ お使いの会社での ZFS の活用方法を改善しましょう。 Klara のエンジニアは、ZFS パフォーマンス監査から新しい ZFS 機能の開発、最終的には ZFS 上でのストレージシステム全体の展開まで、あらゆることについて信頼できることをご存知でしたか？ ZFS サポート ZFS 開発 追加リソース 以下に、お役に立つ可能性のある ZFS に関する興味深い記事をさらにいくつかご紹介します。 ZFS vs Ceph: Ceph は本当に必要ですか？ OpenZFS と SeaweedFS でオブジェクトストレージを使用する データベースのキャッシュと DirectIO を ZFS で管理する ZFS がマルチユーザー/部門メディア制作に最適なファイルシステムである理由 データベースパフォーマンスにとって重要な ZFS ストレージメトリクス さらに表示 すべての ZFS オペレーターがこの会話をしたことがあるでしょう。定期的にスケジュールされた月次 ZFS スクラブが実行され、アプリケーションのレイテンシが 2 日間倍増します。ワークロードは遅くなり、監視アラートが鳴り、ユーザーが不平を言います。スクラブを四半期スケジュールに変更し、次に「監査前」に変更し、最終的には「なし」に変更します。12 か月後、ディスクが故障し、リシルバーが 1 週間かけてゆっくりと進み、2 番目のディスクの潜在的なチェックサムエラーが、通常の交換をバックアップからの復元インシデントに変えます。 メンテナンスがアウトテージになる時 オペレーターの立場からは、スクラブを遅らせるのは合理的です。スクラブは本番環境に目に見える形で損害を与え、その価値はそれを救う日まで見えません。見落とされているのは、その痛みが何を伝えているかということです。スクラブは、ZFS が持つ最低 I/O 優先度で実行される読み取り専用ワークロードです。スケジューラーの最低優先度クラスがアプリケーションを許容できないレイテンシに追い込むことができるなら、そのプールにはパフォーマンスのヘッドルームが全くありません。スクラブはその条件を作り出したわけではありません。それを測定したのです。ストレージシステム内のすべてのデータを読み取るという単純な行為が、保護を低下させるのに十分なパフォーマンスインパクトを引き起こすなら、それは次に起こることからのあなたを救おうとしている炭鉱のカナリアです。 スクラブが実際に行うこと スクラブは、プール内のすべての割り当て済みブロックをウォークし、そのチェックサムをそれを参照するブロックポインタと比較して検証します。健全なプールでは何も見つかりません。健全でないプールでは、ビットロト、セクターの故障、および誤った書き込みを、まだ冗長性があって修復できるうちに見つけます。これがその全体的な目的です。 OpenZFS 0.8 以降、スクラブは 2 つのフェーズで実行されます。最初のフェーズは、プール内のメタデータ、つまりすべてがディスク上のどこにあるかを記述する間接ブロックと dnode のツリーをトラバースし、メモリ内にブロック範囲のソート済みリストを構築します。2 番目のフェーズは、これらの範囲を大きなシーケンシャル読み取りとして発行します。これは、古いブロックポインタ順スクラブからの大幅な改善でした。古いスクラブは、実行全体で多数の小さなランダム読み取りでスピニングディスクを叩いていました。しかし、最初のフェーズは依然としてメタデータトラバーサルに束縛されており、断片化されたプールで小さなブロックが多い場合、そのトラバーサルはソートでは修正できないランダム読み取りワークロードになります。 スクラブ I/O は明示的に優先度が下げられています。ZIO スケジューラーは、インフライトスクラブ読み取り（zfs_vdev_scrub_max_active）をキャップし、VDEV ごとに読み取るべき未処理バイト量（zfs_scan_vdev_limit）をスロットルします。スクラブの痛みを経験するオペレーターは、通常、これらのノブを最初に調整し、ビジネス時間中に実行を一時停止するために `zpool scrub -p` を使用します。 # zpool status tank scan: scrub in progress since Sat Jul 11 02:00:14 2026 18.4T / 214T scanned at 312M/s, 9.1T / 214T issued at 154M/s 0B repaired, 4.25% done, 16 days 02:11:32 to go 214TB プールでの 16 日間の見積もりは、「今月はスキップできるか」という会話のきっかけとなる数字です。チューナブルを下げると、見積もりは悪化します。上げると、本番環境が悪化します。ノブは問題ではありません。プールはこのワークロードのための余地なしに設計されました。 サイジングが間違っていた場所 スクラブ中に苦労するプールは、ほぼ常に 2 つの数値、つまり使用可能なテラバイトと価格でサイジングされていました。プールを健全に保つワークロードは、スプレッドシートに決して組み込まれませんでした。最初の失敗は容量です。プールは初日にデータセットに合わせてサイジングされ、85% から 95% 満杯の状態での定常運用が普通になります。空き容量が減少すると、ZFS の割り当て動作は低下します。アロケーターは連続した領域を見つけるために余分に作業し、空き領域は断片化し、最終的に ZFS はギャングブロックに頼り、単一の論理書き込みを散在する断片に分割します。それらの断片のそれぞれが、次のスクラブが追跡しなければならないブロックポインタです。満杯のプールは断片化されたプールであり、断片化されたプールはスクラブのメタデータフェーズを数百万の小さなランダム読み取りに変えます。 2 番目の失敗は IOPS です。RAIDZ はドルあたりの容量を提供し、VDEV あたり約 1 台のディスクのランダム読み取り IOPS を提供します。これは、VDEV 内の各ディスクが各論理ブロック読み取りに参加するためです。5 つの 12 台幅の RAIDZ2 VDEV で構築された 12TB ドライブ 60 台のシャーシは、約 500TB の使用可能容量と約 750 のランダム読み取り IOPS を提供します。チームは、その 500TB をデータセットと比較して購入注文に署名します。誰も 750 IOPS を本番負荷と同時メタデータトラバーサルと比較しません。これはまさにスクラブ、リシルバー、または大きなスナップショット削除が要求するものです。3 番目の失敗は、メンテナンスに予算が割り当てられないことです。サイジングはアプリケーションワークロードをモデル化し、そこで停止します。しかし、スクラブ、リシルバー、スナップショットクリーンアップ、および send/receive レプリケーションは、本番プールではオプションの追加機能ではありません。それらは、システムの寿命の間、定期的なスケジュールで実行される本番ワークロードです。アプリケーションをかろうじてサービスできるサイジングのプールは、自身の維持費を賄えないプールであり、月次スクラブはその赤字が集められる場所です。 修正の経済性 正直な修正は、より多くの VDEV、より狭い VDEV、またはミラー、そしてより低い使用率です。これらすべてには費用がかかり、顧客に容量を追加せずにスピンドル数を倍増するように言うことは、ほとんど進展のない会話です。ハードウェア予算は現実的な制約であり、それらを無視する設計アドバイスは役に立ちません。 代わりに利用すべき非対称性が存在します。スクラブとリシルバーの痛みはメタデータに集中します。小さなブロックがプール全体に散在し、依存関係順に読み取られます。スピニングディスクはまさにこの点で劣っており、スクラブの第 2 フェーズを支配する大きなシーケンシャル読み取りには依然として優れています。痛みを引き起こすワークロードは、容量のごく一部です。その一部を、そのタイプのワークロード向けに構築されたメディアに移動させます。 特別な VDEV によるメタデータオフロード OpenZFS の割り当てクラスにより、プールは特別な VDEV（通常はエンタープライズ SSD または NVMe デバイスの幅広ミラー）を保持できます。これは、すべてのプールメタデータ（間接ブロック、dnode、spacemap、dedup を実行している場合は DDT も）を受け取ります。データブロックはスピニングディスク上に残ります。 # zpool add tank special mirror nvme0n1 nvme1n1 nvme2n1 スクラブ動作への影響は直接的です。HDD 上でランダム読み取りの嵐を発生させていたメタデータトラバーサルフェーズは、SSD 上で 5 桁または 6 桁の IOPS で実行されるようになり、スピニングディスクは得意とするシーケンシャルデータ読み取りのみを処理します。痛みを引き起こすワークロードは、容量のごく一部です。その一部を、そのタイプのワークロード向けに構築されたメディアに移動させます。 メタデータオフロードと特別な VDEV OpenZFS の割り当てクラスにより、プールは特別な VDEV、通常はエンタープライズ SSD または NVMe デバイスの幅広ミラーを保持できます。これは、すべてのプールメタデータ（間接ブロック、dnode、spacemap、dedup を実行している場合は DDT も）を受け取ります。データブロックはスピニングディスク上に残ります。 # zpool add tank special mirror nvme0n1 nvme1n1 nvme2n1 スクラブ動作への影響は直接的です。HDD 上でランダム読み取りの嵐を発生させていたメタデータトラバーサルフェーズは、SSD 上で 5 桁または 6 桁の IOPS で実行されるようになり、スピニングディスクは得意とするシーケンシャルデータ読み取りのみを処理します。リシルバー