スナップショットを多用するホームサーバーのワークロードでBtrfsのメタデータ枯渇を防ぐ方法
スナップショットを多用するBtrfsサーバーでは、未割り当てチャンクの余裕を確保し、ENOSPCが発生する前にメタデータの変動を抑えることで、メタデータの枯渇を回避できます。
この記事では、ファイルシステムがまだ正常で書き込み可能な状態であることを前提とします。目的は、メタデータの割り当て、未割り当てデバイス領域、スナップショット数、オブジェクトの変動を早い段階で監視し、ENOSPC修復ガイドで扱う復旧状態にサーバーが到達しないようにすることです。問題はスナップショットの頻度だけではありません。保持期間、更新パターン、atimeの書き込み、数百万に及ぶファイルシステムオブジェクト、そしてメンテナンスのタイミングが組み合わさり、メタデータの圧迫がどれだけ速く進むかを決定します。
メタデータと未割り当て領域をまとめて追跡する
通常の日と、最も負荷の高いスナップショットまたはバックアップの時間帯の後に、btrfs filesystem usageの結果を記録します。dfだけに頼らず、割り当て済みメタデータ、使用中のメタデータ、データの割り当て、未割り当てデバイス領域を追跡してください。
Btrfsストレージの解説では、ファイルシステムが追加のメタデータ容量を必要とした際に、未割り当て領域が新しいチャンクの原資になることが説明されています。
アラートには、どのワークロードにも当てはまる一律の割合ではなく、利用状況に合った保守的な余裕の下限を設定してください。有用な指標は「メタデータの70％が使用中」という単純な値ではなく、Btrfsが次に必要なメタデータのブロックグループを作成できるだけの未割り当て領域をまだ確保しているかどうかです。
ENOSPCが自己強化的になる前にアラートを出す
メタデータが枯渇すると、スナップショットやファイルの削除にもメタデータの更新が必要になるため、クリーンアップが難しくなることがあります。未割り当て領域の減少を早期警告として扱い、通常のメンテナンスコマンドがまだ処理できる余裕のあるうちに対処してください。
ENOSPCに関する詳しい資料では、ENOSPCは余裕の不足から始まるのであり、ファイルシステム上の見かけ上の全バイトが消費された時点でのみ発生するわけではないと説明されています。
下限を下回ったら、まず新しいスナップショットの作成とメタデータ負荷の高いジョブを一時停止します。アラートが発生したというだけで大規模なリバランスを開始しないでください。どの領域クラスが圧迫されているかを確認し、最小限の修正作業に必要な作業領域を十分に確保してください。
スナップショットの頻度だけでなく保持期間も制限する
古いスナップショットが予測どおりに削除され、データの変動が中程度であれば、1時間ごとのスナップショットも現実的です。危険なのは、頻繁に変更されるファイルを多数の世代にわたって保存し続ける、際限なく増加する履歴です。
実用的なSnapperの設定例では、自動作成されたスナップショットを無期限に蓄積させるのではなく、保持期間によってスナップショット履歴を制限する方法が示されています。
保持期間は復旧上の価値に基づいて決めてください。頻繁に変更される設定には短期間の復旧ポイントを多めに用意し、変動の大きい仮想マシンイメージやコンテナデータには長期間の復旧ポイントを少なめにします。ローカルスナップショットの容量を超える復旧期間が必要なデータについては、独立したバックアップも用意してください。
スナップショットの期間内に発生するメタデータの変動を減らす
有用なファイル内容を変更していないのにメタデータを書き換えるワークロードを探してください。たとえば、頻繁なアクセス時刻の更新、オブジェクト数が非常に多いパッケージツリーやコンテナツリー、ローテーションされるキャッシュ、スキャンのたびに多数のディレクトリを更新するアプリケーションなどです。
LWNのBtrfsスナップショットに関する分析では、通常のスナップショットが最初は既存のデータとメタデータを共有しているにもかかわらず、atimeの更新がスナップショットの変動を増幅することが指摘されています。
ワークロードに適したマウント設定やアプリケーション設定を使用し、安全な場合は不要なアクセス時刻の変動を避けてください。アプリケーションの要件を理解せずにメタデータ機能を全体で無効にしないでください。まずは復旧上の価値がない書き込みを減らします。
メタデータの増加を傾向として監視する
プール容量と同じダッシュボードで、メタデータの使用量とBtrfsのエラー統計を収集します。スナップショット数、コンテナのデプロイ、バックアップジョブ、大規模なファイルツリーの変更と、日ごとおよび週ごとの増加量を比較してください。
Netdataの現在のBtrfsコレクターでは、ストレージ圧迫が停止を引き起こす前に傾向を把握できるよう、メタデータの使用量を監視できます。メタデータの圧迫が対話的なトラブルシューティング中にしか見えない状態を避けられます。
絶対値のしきい値だけでなく、増加傾向にもアラートを設定してください。新しいバックアップポリシーの導入後にメタデータが毎日数GBずつ増加するサーバーは、残りの余裕が危険な水準に達するずっと前に調査が必要です。
保持期間を延長する前にスナップショットを多用するワークロードをテストする
スナップショットの頻度を高めたり、新しいコンテナ、バックアップツール、小さなファイルが多いワークロードを追加したりする場合は、ポリシーをサーバー全体に適用する前に、代表的な1サイクルでメタデータの増加量を測定してください。
最近のBtrfs内部構造に関する記事では、メタデータがファイルシステムの構造を追跡するのであり、メタデータが総ファイル容量だけで決まる固定的なオーバーヘッドではないと説明されています。
メタデータの増加が予測可能で、保持期間に沿ってクリーンアップが実行され、通常のメンテナンス後に未割り当て領域の余裕が回復しているなら、予防ポリシーは機能しています。書き込みに失敗し始めた場合や、ファイルシステムがすでに割り当て用の作業領域を使い果たしている場合は、関連するZimaSpaceの記事BtrfsメタデータENOSPCからの復旧が適切な次の対応です。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
