なぜホームNASアプリと大量アーカイブは同じストレージプールで競合するのですか？

ホームNASのアプリと大量アーカイブは、まったく異なる種類のパフォーマンスを重視する2つのワークロードを1つのストレージプールでスケジューリングしなければならないため、競合します。

アプリは小さくレイテンシーに敏感な読み取り、データベースのコミット、ログ、メタデータの変更を生成します。アーカイブジョブは長い連続ストリームを移動し、利用可能なすべてのメガバイト毎秒を消費しようとします。両者が同じプールを使うと、デバイスのキュー、キャッシュ、ファイルシステムの割り当て、ライトバック、パリティ作業、リカバリリスクを共有し、ディスク容量だけでなく影響を及ぼします。

小さなアプリI/Oは長いアーカイブキューの後ろで待機する

アーカイブコピーは多くの大きなリクエストを保留にできます。これによりストレージパイプラインが常に稼働しスループットが上がりますが、キューの後ろに到着したアプリのリクエストは自身のサービス時間よりもはるかに長く待たされることがあります。ダッシュボードは遅く感じられても、転送ウィンドウは優れた帯域幅を報告します。

これはレイテンシーとスループットの対立です。現在のPostgreSQLストレージテストでは、WAL、チェックポイント、インデックス読み取り、同時クライアントが同じキューを深くする様子がストレージキュー飽和ベンチマークで説明されています。ホームNASはクライアント数が少ないですが、バックアップやアーカイブワーカーがアプリケーションデータベースの隣で同様の競合パターンを作り出すことがあります。

共有プールはディスク以上に競合ポイントが多い

リクエストはまずアプリケーションキャッシュ、OSページキャッシュ、ファイルシステム、ブロックスケジューラ、仮想プール、デバイスファームウェアに到達します。圧縮、暗号化、チェックサム、パリティはリクエストがドライブに届く前にCPUやメモリの負荷を増やすことがあります。したがって、プールはディスク利用率が中程度でも上位レイヤーで既に作業が遅延していることがあります。

Linuxは帯域幅だけではインタラクティブサービスを保護できないためストレージ制御を公開しています。I/Oレイテンシーコントローラガイドは、保護されたワークロードが目標を逃した場合にキュー深度や人工的な遅延を調整する方法を説明しています。この設計自体が根本的な問題を示しています。同じデバイス上のピアはファイルを共有しなくても互いに悪影響を及ぼす可能性があります。

キャッシュは一方のワークロードを助け、もう一方はそれを追い出す

アプリデータベースやインデックスは、小さなホットな作業セットがメモリに残ると恩恵を受けます。一度きりのアーカイブスキャンは再利用されないデータでページキャッシュを満たし、それらのホットページを押し出します。アーカイブが終わった後も、アプリは作業セットをストレージから再読み込みする間遅くなることがあります。

これはキャッシュを全面的に無効にする理由ではありません。むしろ、1つの追い出しポリシーが相容れない目標に対応していることを認識すべき理由です。ワークロード特化型ページキャッシュ追い出しの研究では、アプリケーションがアクセスパターンに適したポリシーを使えるときにスループットとテールレイテンシーの改善が見られました。小規模なサーバーではスケジューリング、レート制限、または別々のデータセットで同じ衝突を減らせます。

ライトバックとメンテナンスが競合を長引かせる

コピーの進行バーは停止しても、ダーティページのフラッシュは続きます。同時にチェックサム、圧縮、スナップショットの変更、パリティ更新がプールを占有していることもあります。目に見える転送が終わった後に始まるアプリは、満杯のライトバックキューを引き継ぎ遅延した停止を経験することがあります。

バックアップソフトウェアはこの副作用を直接文書化しています。バックアップI/Oのスロットリングはレイテンシーに敏感なデータベース作業への負荷を制限します。より広範なバックアップリソース分析は、ストレージ、ネットワーク、処理の制限を単一のディスクのせいにするのではなく総合的に考慮すべき理由を示しています。

分離はスケジューリングと障害境界を変える

アプリとアーカイブのプールを分けると、それぞれのワークロードに独自のキュー、キャッシュポリシー、空き容量の挙動、メンテナンスウィンドウが与えられます。1つのプール上の別々のデータセットはレコードサイズ、スナップショット、クオータポリシーを改善できますが、物理デバイスは共有します。I/O制御はデータを移動せずにレイテンシーを保護できますが、プールが飽和すると競合するジョブのスループットを意図的に減らします。

適切な境界は症状によります。アーカイブのウィンドウだけがアプリの停止を引き起こすなら、スケジューリングやスロットリングで十分かもしれません。データベース、サムネイル、コンテナが一日中レイテンシーに敏感な場合は物理的分離がより強力な隔離を提供します。カーネルのレイテンシーベースのワークロード保護はこのトレードオフを明示しています。保護されたサービスが目標を逃すまではストレージは作業を最大限活用し、その後は大量作業が譲る必要があります。

よくある質問

高速なSSDプールはアプリとアーカイブの競合を止めますか？

飽和点は上がりますが、共有キュー、キャッシュ追い出し、ライトバック、メンテナンスはなくなりません。十分な同時作業があれば高速ストレージでもアプリのレイテンシーは増加します。

別々のデータセットは別々のプールと同じですか？

いいえ。データセットはポリシーや会計を分けられますが、リクエストは同じ物理デバイスに届きます。別々のプールはより強力な物理I/O境界を作ります。

アーカイブジョブは常にスロットルすべきですか？

レイテンシーに敏感な作業と重なる場合やサーバーを不安定にする場合のみです。営業時間外のスケジューリングはフルスループットを維持でき、継続的な混在使用は明示的なI/O制限を正当化するかもしれません。