タイトルの質問に答えると、TL;DR

Question

最初に：私は6〜7年後の発展について推測するつもりはありません。これは今日と近い将来についての話です。要約、この回答の下部を参照してください。

現在、ZFSではプールからvdevを削除することはできません。また、ネイティブの「再バランス」機能もありません（ブロックポインタの書き換え、bp 書き換えまたはbpo 書き換え詳細については、こちらをご覧ください。ZFSするミラーリングされた vdev の冗長性レベルを下げることができますが、raidzN ではそれができません。ただし、これは必要なことではありません。(ZFS では、何も言わないとストライピングが行われます。)

基本的に、プールは1つ以上のストレージデバイスで構成されたストライプセットと考えることができますが、後者（vdev）のみが冗長構成で配置できます。各vdevを任意の高いレベルの冗長性で構成できますが、毎プールが完全に機能するためには、プール内のvdevが冗長性しきい値を超えている必要があります。vdevに障害が発生すると、せいぜい失われるのはその vdev に保存されていたデータのみであり、どのデータがどの vdev に保存されるかを積極的に制御する方法はありません (別の欠点がある別のプールに配置する以外)。

最初の拡張後に説明したような「ミラーリングされた」プールがある場合、実際には2つのvdevがあり、それぞれがミラーリングされた物理ストレージデバイスのペアで構成され、2つのvdevがストライプ化されてプールを形成します。2つのvdevと2つのドライブのミラープールは、1つのドライブの故障によってダウンする可能性があります。1つ他のミラーセットが正常に動作している場合でも、そのミラーセット内の他のドライブで不幸なエラーが発生します。このような障害が発生した場合、他に何が起こっても、一部のデータが失われます。

ZFSプールの容量を増やす通常の方法は、ドライブを元の状態に戻すより大きなサイズの場合は、プールを新しいドライブに再同期させてから、使用されなくなった古いドライブを物理的に取り外します。通常、zpool replaceプロセス全体を通じて必要な冗長性レベルを維持するために、古いドライブと新しいドライブの両方を接続した状態でこれを使用します。通常の代替手段は、プール内の既存の vdev と同じ冗長性レベルの vdev を追加することです。繰り返しますが、ZFS はストライプセットの一部の削除をサポートしておらず、プールは厳密にストライプ vdev で構成されているため、追加した vdev を削除することはできません。多くの ZFS 初心者がこの罠に陥り、使用するコマンドに注意を払わないと簡単に失敗します。

ZFS 再シルバーリングの仕組み上、再シルバーリングは関係するドライブにとって非常に苦痛な作業です。従来の RAID 再シルバーリングは、通常、ほとんどがシーケンシャルで、ユーザーアクティビティによるランダム I/O が少し混じっていますが、ZFS 再シルバーリングは、ユーザーアクティビティによるランダム I/O が混じった、ほぼ完全なランダム I/O です。ミラーセットは、その寿命を通じてほぼ同じアクティビティを経験しています。1 つのドライブが限界状態、または故障した場合、もう 1 つのドライブもせいぜい限界状態である可能性が高くなります。再シルバーリングの試練を何日も続ければ、簡単に限界を超えてしまう可能性があります。(個人的な経験から言うと、6 TB のデータを再シルバーリングするには、約 1 週間かかる再シルバーリングプロセスになると思います。最大11純粋なシーケンシャルスループットに基づくと（ZFSのディスク上のフォーマットと再シルバリング戦略を考えるとまったく非現実的ですが）、少なくともドライブにとって、約 17 時間の恐怖です。私の推測では、6 TB の再シルバー化を、おそらくその 2 倍、つまり 1 日半のドライブ酷使よりも短くする方法はないと思われます。

また、2x24TBや2x12TBのミラー構成が実現したとしても、非常に疑問に思う。現在のドライブサイズでは、すでに物理的限界を超えている（しゃれではない）。ウレは、現在と同程度（1ビット読み取りあたり10^-14～10^-15セクターエラー、メーカーのデータシートではずっとこの数値で推移）ですが、統計的には12TBドライブの完全読み取りで少なくとも1つのエラーが発生することはありません（12TBは約9×10^13ビットで、10^14に丸められます）。これを24TBドライブに拡大すると、統計的に少なくとも1 回の完全読み取りパスで 1 つか 2 つのフルセクタエラーが発生します (約 2*10^14 ビットを読み取っているため)。10^-15 URE ドライブを使用しても、あまり意味がありません (その場合、半分の読み取りパスではなく、5 つの読み取りパスが必要になります)。これはもちろん統計と仕様です。実際には、読み取りエラーは密集する傾向があり、ドライブは、ある時点でエラーを次々と発生させるまで、多数の完全読み取りでは問題なく動作する場合があります。

ほとんどの非サーバースピナーの保証期間は 1 ～ 3 年なので、どのセットもそれより長く動作し続けるとは考えられません。一方、あなたの計画では、交換されるまでに少なくとも 6 年間は機能し続けることになっています。サーバースピナーでさえ、通常は 5 年間の保証期間しかありませんが、通常は 24 時間 365 日稼働が 5 年間です。私の個人的な経験では、Seagate の Constellation ES シリーズなどのハイエンドの消費者向けドライブは、ほぼこのレベルの稼働に耐えられると、故障してデータ天国に向かいます。(個人的な逸話: 1 TB の Constellation ES.2 は、故障するまで使用しませんでしたが、おかしな動作を始めた頃には 4 年 9 ～ 10 か月ほど使用していました。)

一般的に、ZFS を実行する多くの人は、スピナーのサイズが 3 ～ 4 TB に達すると二重冗長化を採用し、より重要なデータの場合はそれより小さくすることを検討してください。これには十分な理由があります。ストレージデバイスが故障するそしてそれは驚くほど頻繁に起こるZFSの場合、プラッターからまだ読み取り可能な生のビットを復元する以上のことを望むなら、はるかに高価なデータ復旧サービスも検討する必要があり、ZFSプールをリモートで処理できるデータ復旧ソフトウェアは知りません。ZFSがプールをインポートできない場合、最も実用的な答えは、バックアップしていないプール上のデータをすべて失われたと見なすことです。他の場所。

タイトルの質問に答えると、TL;DR

FreeNAS/ZFSでストレージをこのように管理できますか

厳密に言えば、そうすべきです。しかし、私は本当にまったくお勧めしません。ハードウェアの運用限界をあまりにも押し広げすぎています私にとっては、それを支持することはおろか、快適に感じることもできません。(この答えは、質問されているファイルシステムに関係なく、ほぼ同じになることに注意してください。)

Answer 1