異なるドライブを再利用する場合と同一構成のプールを再構築する場合：どちらがより予測しやすい復旧を実現する？

エヴァ・ウォン

IceWhale author

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

Reuse Mixed Drives vs Rebuild a Matched Pool: Which Makes Recovery More Predictable? - Zima Store Online

システムがドライブの容量とインターフェースに対応し、すべてのディスクが完全な健康状態テストに合格し、データがより複雑な交換・復旧構成に耐えられるなら、容量の異なるドライブを再利用してください。NASに主要データを保存し、予測可能な容量、再構築の挙動、スペア計画、文書化が新しいドライブの費用回避より重要なら、容量と仕様を揃えたプールを構築してください。「揃える」とは、必ずしも同一の製造ロットにすることではなく、プールの役割と技術要件に合わせることを意味します。

コスト比較ではなく、互換性の確認から始める

容量の異なるドライブが自動的に危険というわけではなく、容量と仕様を揃えたドライブが自動的に信頼できるわけでもありません。最初に確認すべきなのは、候補となるすべてのディスクがコントローラーまたはNASでサポートされ、互換性のあるインターフェースとセクターフォーマットを使用し、必要な容量以上を備え、選択したプールレイアウトで予測可能に動作するかどうかです。

異なるドライブを使用したRAID交換テストをまとめた記事では、同じインターフェースを使用し、ブロックサイズに互換性があり、十分な容量を備えたドライブであれば、複数のシステムで正常に再構築できることが確認されています。また、互換性のないインターフェース技術や、特定のセクターフォーマットの組み合わせなど、明確な制限も示されています。

プラットフォームが、提案する容量混在セットの割り当て方法と交換方法を明確に報告できない場合は、プールの作成前に中止してください。最初のディスク障害で、交換経路がテスト済みではなく想定に基づいていたことが判明するなら、低コスト構成は経済的とはいえません。

判断軸	容量の異なるドライブを再利用	容量と仕様を揃えたプールを構築
初期費用	すでに所有している正常なドライブを使う場合は最も低い	調整済みのセットを購入する必要がある
使用可能容量	プールモデルと最小メンバー容量のルールに大きく左右される	導入前に計算しやすい
パフォーマンス	最も遅いメンバーや、vdevの不均一な挙動を引き継ぐ可能性がある	ドライブのクラスと容量が揃っていれば、より一貫性が高い
交換計画	ドライブごとに互換性と容量の記録が必要	文書化した1つの最低仕様で、グループ全体をカバーできる
再構築の見通し	ドライブの速度、使用年数、レイアウトによって変動する可能性がある	1つのプール設計のもとで、テストと見積もりが容易
障害診断	モデル、使用年数、履歴が異なるため、変数が増える	よりクリーンな初期状態。ただし、障害が相関して発生する可能性は残る
最適な用途	二次ストレージ、ラボ、メディア、または容量重視のプール	明確な復旧目標が定められた主要データ

容量の異なるドライブを再利用するのが合理的なケース

ディスクの使用履歴が把握でき、拡張SMARTテストと表面テストに合格し、ストレージモデルが容量の異なるドライブに対応しているなら、再利用は合理的です。異なる容量に対応したレイアウトなら、ドライブを一度に購入するのではなく段階的にアップグレードする場合でも、従来のストライプ型RAIDより既存容量を多く維持できる可能性があります。

容量が混在するストレージレイアウトに関する実用ガイドは、運用モデルが重要である理由を示しています。従来のRAIDとRAIDZでは通常、最小ディスクに合わせてメンバーのサイズが決まりますが、SHRとUnraidでは割り当てルールが異なり、大容量ドライブの容量をより多く活用できます。

この方法は、データを再取得できる、または別途バックアップされており、性能要件が中程度で、所有者がドライブ単位の在庫管理を受け入れられる場合に最も効果的です。ベイがすべて空いているというだけの理由で、無関係な古いディスクを1つのプライマリプールに組み込むと危険になります。

一致したプールで実際に予測しやすくなること

一致したプールでは、容量計算、予想性能、熱設計、予備ドライブの選定、復旧手順が簡素化されます。管理者は、障害発生時に各メンバーを確認して判断する代わりに、交換に必要な最小容量、インターフェース、セクターフォーマット、そしておおよその再構築プロファイルをそれぞれ1つずつ文書化できます。

一致させることで、低速なメンバーや容量がほぼ満杯のメンバーによってメンテナンス時間が長引く可能性も減ります。Dong Knows Techのストレージ概要では、標準RAIDはドライブ容量を一致させる設計になっていると説明されています。容量が混在する場合、最小容量のドライブに制限されることがよくあります。

利点は、故障しないことではなく、運用の一貫性です。同じラベルでも同じ健康状態が保証されるわけではありません。また、一致したプールでも、スクラブ、アラート、バックアップ、テスト済みの交換用メディア、そして元のシャーシに依存しない復元手順が必要です。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

一致している必要はあっても、同じ製造バッチである必要はない

予測可能な復旧に重要なのは、技術的な一致です。使用可能容量、インターフェース、セクターフォーマット、ワークロードクラス、持続性能、そしてコントローラーとの互換性が該当します。すべてのドライブを同じ生産ロットから購入すれば調達は簡単になるかもしれませんが、独立した故障履歴が生まれるわけではありません。

堅実な構成では、同じ容量とドライブクラスを使いながら、購入時期をずらしたり、別の調達先から入手してテスト済みの予備を保管したりできます。目的は、同じシリアル番号がより強い冗長性を生むかのように装うことではなく、構成に関する不確実性を減らすことです。

この区別により、高くつくミスも防げます。つまり、まったく同じモデルが入手できないという理由で、互換性のある交換用ドライブを廃棄してしまうことです。同じインターフェースで容量の大きいドライブは、故障したメンバーの代わりに使えることが多いものの、他のメンバーをアップグレードするまで、プールでは追加容量を利用できない場合があります。

年数と健全性によって、容量の優位性が逆転することがある

異種ドライブを混在させると、新たな購入なしでより多くの使用可能テラバイトを確保できるように見えるかもしれません。しかし、再割り当てセクターの増加、コマンドタイムアウト、振動履歴、または過去の使用状況が不明な古いディスクによって、その容量が短い移行期間しか残されていない状態になる可能性があります。SMARTデータは証拠であって保証ではないため、完全な読み取りテストと明確な使用履歴が重要です。

新しい一致構成のプールにも初期段階のリスクがあるため、重要なデータを移行する前にバーンインを実施する必要があります。プールを構築し、拡張テストを実行し、スクラブを行い、代表的なデータをコピーして、古いシステムを廃止する前に復元を検証します。新しいドライブを、設置当日に唯一のコピーにしてはいけません。

再利用するディスクが健全でも、必要な復旧時間に対して容量が小さすぎる、または速度が遅すぎる場合は、セカンダリ用途に割り当てます。すべてをプライマリプールで使うか、すべてを廃棄するかの二択にする必要はありません。

復旧の予測可能性は、ラベルよりもレイアウトに左右される

ミラー、パリティvdev、独立ディスクアレイ、ファイルレベルのパリティシステムでは、障害発生時の挙動も再構築方法も異なります。従来型vdev内でドライブを混在させると、容量を無駄にしたり、最も遅いメンバーの性能を引き継いだりする可能性があります。一方、互換性のあるペアを別々のグループに分ければ、より明確な障害境界を維持できる場合があります。

異種ドライブNAS構築におけるストレージモデルに関するZimaSpaceの比較では、同じハードウェア構成でも、従来型RAID、Unraid、手動で構築したLinuxストレージによって、使用可能容量と復旧時の責任が異なる理由を説明しています。

ここが判断の境界です。プラットフォームのストレージモデルが、明確でテスト済みの異種ドライブ復旧手順をすでに提供しているなら、見た目を統一するためだけにすべてのディスクを交換する価値はほとんどありません。復旧が文書化されていないパーティション、互換性のないグループ、または手動再構築の知識に依存するなら、再構築する意義があります。

復旧ドリルで2つの選択肢を比較する

すべてのドライブのモデル、容量、セクターフォーマット、使用年数、健全性の結果、物理ベイを記録します。
生ドライブの合計容量ではなく、正確なプール構成に基づいて使用可能容量を計算します。
各メンバーまたはドライブグループに対して、使用可能な最小の交換部品を特定します。
重要でないテスト用メンバーを1台取り外し、劣化時の動作と再構築時間を測定します。
文書化されていないコントローラー変更なしで、交換部品が認識されることを確認します。
プライマリプールが利用できない状態で、バックアップから選択したデータを復元します。
他者が利用できるドキュメントだけを使って、記載された手順を再現します。

予測可能な復旧計画は、複数のディスク障害シナリオにも対応できなければなりません。ホストの損失、エンクロージャーの故障、誤ったプール削除、異なるハードウェアへの復元もテストしてください。RAIDは可用性を高める層であり、RAIDとバックアップによる復旧計画で説明されている独立したバックアップの代替ではありません。

この構成にはどのドライブ戦略が適していますか？

混在ドライブを再利用する場合

各ドライブの履歴が把握され、完全なテストに合格し、容量の異なるドライブ向けに設計されたストレージモデルに適合する場合は、再利用します。プールはセカンダリ用途または完全にバックアップされた状態に保ち、交換ルールをすべて文書化し、メンバーごとに性能と再構築時間が異なる可能性を受け入れてください。

同一仕様のプールを再構築する場合

データがプライマリで、復旧時間が重要であり、緊急時に別の人がディスクを交換する可能性がある場合は、同一仕様のプールを選びます。容量、インターフェース、セクターフォーマット、ワークロードの種類、性能をそろえ、テスト済みの予備ドライブまたは検証済みの調達計画を用意します。

2つのプールによる移行を選ぶ場合

新しい同一仕様のプライマリプールを作成し、データをコピーして検証した後、正常な混在ドライブをバックアップ、アーカイブ、ダウンロード、またはメディア用の容量として再利用します。ZimaCube 2のようなマルチベイプラットフォームでは、ストレージの役割を分けられますが、各プールには独立した障害対策と復元計画が必要です。

よくある質問

RAIDドライブは同じブランドである必要がありますか？

必ずしもそうとは限りません。多くのシステムでは、インターフェース、セクターフォーマット、容量に互換性があれば、異なるブランドのドライブでも再構築できます。コントローラーまたはNASの互換性ルールが最終的な基準となるため、交換用ドライブは緊急時の計画に組み込む前にテストしてください。

同一仕様のプールはより速く再構築できますか？

メンバーの容量と性能がより均一なため、見積もりが容易です。ただし、実際の再構築時間は、使用データ量、プール構成、ドライブの状態、コントローラーの動作、バックグラウンド負荷、さらにシステムがすべてのブロックを再構成するのか、割り当て済みデータだけを再構成するのかによって異なります。

古い混在ドライブはバックアップに使えますか？

ヘルステスト後の追加コピーとしては有効ですが、唯一のバックアップにはしないでください。別の検証済みコピーがあり、復元プロセスもテスト済みであれば、古いメディアはオフライン保管やセカンダリ保管に役立ちます。

最終的な結論

プラットフォームが明示的にサポートし、各ドライブの履歴が把握されていて、プールがセカンダリ用途または別の場所で完全に保護されている場合は、混在ドライブを再利用します。予測可能な復旧、交換の容易さ、明確なドキュメント化が、既存のすべてのディスクを保持することより重要な場合は、同一仕様のプールを再構築します。最も堅実な移行では、まず同一仕様のプライマリプールを作成してコピーを検証し、その後、正常な混在ドライブをより低リスクな用途に割り当てます。