異なるドライブは、レイアウトがそれぞれの違いを吸収できる場合に限って再利用し、埋没コストよりも予測可能な交換、リシルバリングの挙動、容量を重視するなら、同一構成のプールを再構築します。
混在ディスクが自動的に安全でないわけでも、同一ディスクが自動的に高い耐障害性を持つわけでもありません。結果は、トポロジー、最小メンバー容量の制約、記録方式、使用年数の相関、スペアの有無、そしてプール外に完全なリストア手段が存在するかどうかによって決まります。
ドライブのラベルより先にレイアウトのルールを比較する
まずストレージレイアウトから確認します。ミラー、パリティグループ、独立したデータディスクでは、容量の消費方法がそれぞれ異なります。多くのパリティまたはミラーレイアウトでは、必要なすべてのディスクを交換し終えるまで、大容量のメンバーも最小容量のメンバー分しか容量に貢献しません。
ZFSはvdevを中心に冗長性を構成するため、障害時の挙動は1台のディスクに付いた製品上のラベルではなく、vdevに依存します。このZFSストレージとリシルバリングの概要は、トポロジーが復旧経路を左右する理由を理解するのに役立ちます。
ソフトウェアが容量の異なるディスクを、容量を隠したり無関係な障害を連鎖させたりせずに分離できるなら、再利用は妥当です。予定しているレイアウトで複数のドライブ容量を大きく無駄にするなら、同一構成での再構築はすでに運用の簡素化という利点を得ています。
記録方式と健康状態を絶対条件として扱う
候補となるすべてのディスクについて、完全なモデル番号、容量、電源投入時間、エラー履歴、セクターサイズ、インターフェース、記録方式を記録します。モデルレベルで違いがあるため、製品ファミリー名だけからCMRかSMRかを推測しないでください。
管理されたSMRとCMRのリシルバリングテストでは、同じZFSワークロードでも再構築の挙動が大きく異なることが確認されました。重要なのは、混在プールが必ず失敗するということではなく、1台の遅いメンバーが復旧期間全体を左右する可能性があるという点です。
増加している再割り当てセクター、保留セクター、訂正不能セクターがあるディスクは除外します。また、振動、発熱、インターフェース要件が筐体に適合しないドライブも除外してください。
容量だけでなく復旧の予測可能性を比較する
同一構成のプールでは、交換ケースの数を減らせます。スペアのサイズが1種類で、性能が近く、既知の再構築時間を見積もれるため、障害対応手順を文書化しやすくなります。
異なるバッチの混在ドライブであれば、使用年数の相関を下げられる可能性がありますが、例外も増えます。そうした例外をスペアおよび交換計画に明記して初めて、復旧を予測可能にできます。
| 判断要素 | 混在ドライブの再利用 | 同一構成のプール |
|---|---|---|
| 使用可能容量 | レイアウトに依存し、容量を無駄にする可能性がある | 予測しやすい |
| スペア | 複数の容量が必要になる場合がある | 互換性のある1つのクラス |
| 再構築速度 | 最も遅いメンバーに制限される | より安定する |
| 使用年数のリスク | 使用年数を分散できる | 同じバッチの使用年数リスクを共有する可能性がある |
| 移行 | 初期コストが低い | コピー、再構築、リストアが必要 |
移行と次の障害にかかるコストを見積もる
同一構成のプールを再構築するには、一時的な容量の確保、完全なデータコピー、チェックサムまたはファイル数の検証、プールの作成、リストア、権限の検証、ロールバック期間が必要です。これらの手順には、新しいディスクの費用以上の時間がかかる場合があります。
異なるドライブを再利用すれば移行を先送りできますが、次の障害によって、現在の構成を維持できる容量のドライブを緊急購入する必要が生じる可能性があります。再利用のほうが安いと判断する前に、適合するスペア1台と緊急交換用1台の価格を見積もってください。
データが再取得可能なメディアなら、手作業による長時間の復旧も許容できる場合があります。プールに家族のデータ、業務データ、またはVMの状態が保存されているなら、通常は回収できる最大容量よりも、予測可能なリストア時間を重視すべきです。
復旧を優先した判断ルールを使う
すべてのモデルが健康状態のチェックに合格し、レイアウトが有用な容量を維持し、遅いメンバーによって復旧が許容できないほど長引かず、独立したコピーが存在する場合は、異なるドライブを再利用します。すべてのベイを埋めるのではなく、最も柔軟に使えるドライブをコールドスペアとして保管してください。
1台の遅いディスクによって障害期間が長引く可能性がある場合、スペアのサイズが細分化されている場合、またはプールの拡張ですでに大半のメンバー交換が必要な場合は、同一構成で再構築します。レイアウトを決めた後は、小さなファイルに対するSMBテストの手順によって、ネットワークのオーバーヘッドとプールの挙動を切り分けられます。
リストアをテストしていない場合は、どちらの計画も中止してください。冗長性によって一部のディスク障害が発生してもシステムをオンラインに保てますが、検証されていないバックアップの有効性を確認することはできません。
製品比較
もっと読む

アプリのアップデートとロールバックにおけるProxmox上のLXCとDockerの比較
Dockerはアプリレベルのバージョン管理を提供し、LXCはゲストレベルのロールバックを可能にします。より適した方は、安全に復元できる最小の状態単位に応じて決まります。

特権ホームサービスにおけるDockerとLXCのセキュリティ境界
Dockerは用途を絞ってパッケージ化されたアプリに適しており、LXCはより完全なLinuxサービスに適していますが、共有カーネルのリスクを許容できない場合、どちらもVMの代わりにはなりません。

初心者が初めて構築するなら、ターンキー型NAS OSかモジュール型Linuxか
ガイド付きのストレージ運用にはすぐに使えるNASソフトウェアを選び、学習と明確な制御のためにより多くの管理を担う価値がある場合は、モジュール式のLinuxを選びましょう。

