スナップショットを多用する小容量ファイルリポジトリにおけるSATA SSDプールとミラーHDD vdevの比較

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

SATA SSD Pool vs Mirrored HDD Vdevs for Snapshot-Heavy Small-File Repositories - Zima Store Online

スナップショット、再帰的スキャン、同期、保持期間のクリーンアップ、小規模ファイルの復元を予測可能なメンテナンス時間内に完了させる必要がある場合は、SATA SSDプールを選択してください。リポジトリが大規模で、ほとんどの世代がコールド状態にあり、バックグラウンドジョブがユーザーを遅延させずに低速で実行できる場合は、ミラー構成のHDD vdevを選択してください。この比較は、より広範な小規模ファイルの応答性に関する問題がすでに解決された後を対象としています。

これは別のSSD対HDD速度テストではなく、メンテナンスに関する判断です

ZimaSpaceでは、数百万のアクティブな小規模ファイルを対象に、SATA SSDプールと一般的なHDDアレイをすでに比較しています。このより限定的な判断は、リポジトリがスナップショットも作成し、過去の世代を保持し、再帰的な同期を実行し、古いツリーを定期的に削除または期限切れにする段階で始まります。これらのジョブは、変更されるファイルの内容が比較的少ない場合でも、メタデータを繰り返し確認します。

既存の小規模ファイルプールの比較は、通常のブラウジングやアプリケーションの応答性を検討する際の適切な出発点です。メンテナンス作業が独立した運用上の問題になった場合に限り、この記事を利用してください。

判断軸	SATA SSDプール	ミラー構成のHDD vdev
再帰的なメタデータスキャン	シークコストが低く、完了時間を予測しやすい	深いディレクトリツリー全体でシーク待ちになることがある
スナップショット保持のクリーンアップ	通常はユーザーが感じる競合を抑えながら完了する	ライブアクセスと競合し、メンテナンスを長引かせる可能性がある
ファイルベースの同期	stat、open、比較、closeの処理を繰り返す用途に適している	ジョブの頻度が低く、スケジュール実行できる場合に適している
使用可能容量のコスト	保護対象テラバイトあたりのコストが高い	長期保持向けに拡張しやすい
障害復旧	より小規模なアクティブプールなら迅速に復元できる	大量に保持された履歴は、再構築や復元に時間がかかることがある
最適な役割	アクティブなリポジトリと最近の世代	古い履歴、長期保持、容量重視のストレージ

再帰的ジョブで優位性が変わる理由

ファイルベースの同期またはバックアップジョブでは、すべてのディレクトリを調べ、タイムスタンプとサイズを比較し、変更されたファイルを開き、転送されるデータが少ない場合でも大量のオブジェクトを閉じることがあります。数百万のファイルがあると、ネットワークがほとんどアイドル状態でも、メタデータ操作が実時間の大半を占めることがあります。

最近の数百万ファイルにまたがるメタデータ依存のバックアップスキャンに関する分析は、同じ障害パターンを説明しています。システムが大きなエクステントをストリーミングするのではなく、オブジェクトを列挙して比較しなければならないため、スループットが急落するのです。

SATA SSDは、NVMeクラスのシーケンシャル処理経路を必要とせずに、機械式シークの遅延をなくします。ミラー構成のHDD Vdevは単一ディスクより多くの独立したスピンドルを提供しますが、各ミラー・メンバーは、ジョブがディレクトリエントリ、属性、変更されたブロック、ファイル内容の間を移動するたびに、物理的なシークを実行します。

スナップショットによってHDDのメンテナンスがより目立つようになる場面

Copy-on-Writeスナップショットの作成は速くても、世代を保持・削除すると、その後の処理は変わります。古いブロックは参照されたまま残り、変更されたツリーはより多くのメタデータを蓄積し、クリーンアップではどのデータが引き続き到達可能かを判定する必要があります。ユーザーが処理を目にするのは、スナップショットの作成時ではなく、期限切れになったスナップショットの削除時かもしれません。

Linux JournalのBtrfsスナップショットの削除性能に関する報告は、スナップショットのクリーンアップが瞬時の名前空間変更ではなく、意味のあるファイルシステム負荷になり得ることを示しています。正確な挙動はファイルシステム、変更量、保持期間、空き容量によって異なるため、1つの結果を普遍的に当てはめるのではなく、実際のプラットフォームでテストしてください。

SSDを使っても、スナップショットの運用方針が不要になるわけではありません。世代数が多すぎる、空き容量が少ない、大規模な書き換えが発生する、レプリケーションのスケジュールが適切でないといった状況では、長いメンテナンス時間が発生する可能性があります。フラッシュストレージはストレージのレイテンシを低減しますが、参照の追跡、トランザクション処理、保持設定の誤りをなくすわけではありません。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

ミラー構成のHDD Vdevが依然として優位な場面

履歴世代が数十テラバイトを消費し、そのごく一部にしか対話的にアクセスしない場合、HDDミラーは依然として魅力的です。保持するすべてのバージョンにSSD価格を支払うと、別のバックアップコピー、オフサイト保護、または安全な交換に必要な十分な予備容量に割り当てられる予算が減ってしまう可能性があります。

サーバーに別のミラーペアを追加するか、両方のメンバーをより大容量のディスクに交換できる場合、ミラー構成は容量を拡張するためのわかりやすい道筋も提供します。このレイアウトは、単一のワイドvdevよりも多くのランダムI/O経路を提供しますが、コールドスキャンでの回転待ち時間をなくすことはできません。

メンテナンスジョブを夜間に実行でき、スキャン中にユーザーがリポジトリを待たされず、最新のアクティブツリーをRAM上でウォームな状態に保てるほど小さい場合は、HDD構成が優位です。実際の保持設定でシステムが復旧目標とメンテナンス目標を満たしているなら、履歴全体をフラッシュストレージに保存しても、意思決定上の追加の価値はありません。

スナップショットベースのレプリケーションでメディア要件が変わる理由

ファイルレベルのレプリケーションは、名前空間を繰り返し走査します。ブロックベースまたはスナップショットベースのレプリケーションでは、変更されたエクステントを、変更されていない各ファイルを再び開くことなく送信できるため、ファイル単位のメタデータレイテンシーの重要性が低下します。したがって、レプリケーション方式によって、リポジトリにオールSSDのプライマリプールが必要かどうかが変わる可能性があります。

これは判断の停止点です。ファイルベースの同期からスナップショットレプリケーションに変更することでメンテナンス時間枠が不要になるなら、次の購入判断はもはやSATA SSDとHDDミラーの比較ではありません。より効果的な改善は、データ移動方式を変更することでした。

一方、異なるファイルシステムやベンダー間で移植性を維持する必要があるリポジトリでは、ファイルレベルのエクスポートが依然として必要になる場合があります。その場合、予測可能な再帰スキャンと復元は引き続きストレージ要件の一部であり、SSDにはより長期的な価値があります。

ファイルコピーのベンチマークではなく、リポジトリのライフサイクルテストを使用する

現実的な深さ、ファイルサイズ、権限、サイドカーデータを備えた、代表的なディレクトリツリーを作成してください。
コールド状態での再帰的インベントリと、ウォーム状態での再スキャンを測定してください。
ユーザーがリポジトリにアクセスしている間に、通常の数のスナップショットを作成し、期限切れにしてください。
実際の同期またはバックアップツールを、同等のレイテンシーを持つ宛先に対して実行してください。
保持している世代を1つ削除し、クリーンアップが完了するまでのユーザーが体感する遅延を記録してください。
大きなアーカイブを1つだけではなく、多数のファイルを含むディレクトリを復元してください。
想定されるプール使用率と空き容量の確保量でテストを繰り返してください。

空のSSDプールを、断片化してほぼ満杯のHDDプールと比較しないでください。使用可能容量、冗長性、ファイルシステム、保持期間、ネットワーク、空き容量のポリシーを揃えてください。目的は、他のすべての条件を固定したうえで、ストレージメディアの変更がメンテナンス結果に影響するかどうかを判断することです。

リポジトリに適したレイアウトはどれですか？

SATA SSDプールを選択する場合

スナップショットのクリーンアップ、再帰的なインデックス作成、増分バックアップ、ウイルス対策スキャン、ソースツリーの同期、小さなファイルの復元でユーザーが遅延を感じる場合は、SSDを選択してください。冗長化とバックアップでプールを保護し、耐久性はシーケンシャルなファイルコピーの評価値ではなく、メタデータの書き込み、変更量、スナップショットの挙動を基準に見積もってください。

HDDミラーvdevを選択する場合

保持する履歴が大容量で、メンテナンスをスケジュールでき、小さなファイルの大半がコールド状態である場合は、HDDミラーを選択してください。十分なRAMを搭載し、空き容量を確保し、スクラブとバックアップの実行時期をずらし、障害復旧が許容時間内に収まることを確認してください。

分割リポジトリを使用する場合

現在作業中のツリーと最近の世代をSSDに保持し、古い変更されないスナップショットやエクスポートしたアーカイブをHDDへ移動します。ZimaCube 2のようなシステムでは、両方のストレージの役割を担えますが、移行と復元の手順は文書化しておく必要があります。

よくある質問

小さなファイルでは、HDDミラーはパリティプールより高速ですか？

通常、より多くの独立したI/Oパスを提供し、パリティ書き込みのオーバーヘッドの一部を回避できますが、機械的なシークは依然として発生します。結果は、ミラーの数、キュー深度、RAMキャッシュ、ファイルシステム、断片化、そしてワークロードがデータを読み取るのか再書き込みするのかによって異なります。

RAMを増やせばSSDは不要になりますか？

RAMは、特にスキャン完了後のウォーム状態では、メタデータやファイルの繰り返し読み取りを高速化できます。しかし、すべてのディレクトリ世代、復元要求、変更されたワーキングセットを常駐させ続けることはできません。コールドスキャンや書き込みの多いメンテナンスでは、依然としてストレージにアクセスします。

何百万ものファイルをアーカイブにまとめるべきですか？

コールドツリーをアーカイブ化すると、ネームスペースのオーバーヘッドを削減し、一括転送を高速化できます。ただし、ランダムアクセス、重複排除、増分更新、部分復元の動作が変わります。復元ワークフローが実用的なままであることを確認したうえで、変更されない履歴にのみアーカイブを使用してください。

最終結論

アクティブな使用中でもスナップショットの多い小さなファイルのメンテナンスを予測可能な状態に保つ必要がある場合は、SATA SSDプールを選択してください。スキャンやクリーンアップの速度よりも容量と長期保存を重視する場合は、HDDミラーvdevを選択してください。混在するリポジトリでは、アクティブなツリーと最近の復旧ポイントをフラッシュストレージに保持し、古い履歴を保護されたHDD容量へエクスポートします。