FreeNAS / ZFSは私のストレージをこのように管理させてくれますか？
私はFreeNASを検討しています。事前に、ストレージで何ができるか、何ができないかについての私の理解が正しいことを確認したいと思います。
初期ビルドアウト：2 x6TBドライブが相互にミラーリングする1つのストレージプール。合計有効容量は6TBです（丸めとオーバーヘッドは無視します）。
最初の拡張（2。5〜3年後）：2 x12TBドライブをサーバーに追加します。それらを2番目のミラーリングされたペアとして構成し、既存のストレージプールに追加します。使用可能なストレージを18TBに増やします。
2番目の拡張フェーズ1（5。5〜7。5年後）：2 x24TBドライブをサーバーに追加します。それらをミラーリングされたペアとして構成し、既存のストレージプールに追加します。使用可能なストレージを42TBに増やします。
2番目の拡張フェーズ2（フェーズ1の直後）：6TBドライブからすべてのデータのバランスを取り直し、プールから削除してから、サーバーから物理的に削除します。残りの使用可能なストレージは36TBです。
ここでの私の考えは次のとおりです。
3年ごとに必要なストレージ容量が2倍になることは、2008年から現在までのWHSサーバーでの私の経験の継続です。
24台のTBドライブを追加した後、6台のTBドライブは、ストレージ全体のごくわずかな部分（1/7）しか提供せず、信頼性が十分に古くなっています。それらを（バスタブ曲線の間違った側に）保持すると、より重大な懸念事項になります。それらが生き残った場合、私の成長率では、48TBドライブを購入する必要が生じるまでの時間が半年以上延長されるだけです。 ;だから、彼らは本当に私に多くの時間を与えないでしょう。
ドライブを4つに制限すると、NASにコンパクトなmini-ITXフォームファクタを使用できます。それを超えると、セットアップがより大きく、より高価になります。 （ワイヤーが蛇行しているオープンケースの上部にある2台のドライブは、移行時間の1日か2日は許容されますが、それ以上の期間は許容されません。）
また、以前の約3年間のアップグレード（1.5〜3 TB（2012）および3〜6 TB（現在/近い将来））と同様に、より大きなドライブの可用性についても通常どおりビジネスを想定しています。そして、新しいドライブが利用可能になったとしても、使用できるほど信頼性が高くなります（つまり、レイドの黙示録は決して起こりません）。
まず最初に： 6〜7年後の開発について推測するつもりはありません。これは今日についてであり、最も近い未来です。 TL; DRについては、この回答の下部を参照してください。
今日のZFSでは、プールからvdevを削除することはできません。また、ネイティブの「リバランス」機能もありません（ block-pointer rewrite 、 bp rewrite 、またはを検索してください] bpo rewrite これについて詳しくはこちらをご覧ください）。 ZFS does を使用すると、ミラーリングされた冗長性レベルを下げることができますが、raidzN、vdevはできませんが、それは必要なことではありません。 （ZFSでは、何も言わないときにストライピングが得られます。）
基本的に、プールは、それぞれ1つ以上のストレージデバイスで構成されるストライプセットと考えることができ、後者（vdevs）のみを冗長構成で配置できます。各vdevを任意の高レベルの冗長性に設定できますが、プールが完全に機能するためには、プール内のすべての vdevが冗長性のしきい値を超えている必要があります。 vdevに障害が発生した場合、せいぜいそのvdevに保存されたデータのみが失われ、どのデータがどのvdevに保存されるかをアクティブに制御する方法はありません（それらを配置する以外に）他の欠点がある別々のプールで）。
最初の拡張後に説明するような「ミラーリングされた」プールがある場合、実際にあるのは2つのvdevであり、それぞれがミラー化された物理ストレージデバイスのペアで構成され、2つのvdevがストライプ化されてプールを形成します。 2つのvdev2つのドライブ-各ミラープールは、他のミラーセットであっても、1つの障害が発生したドライブと、そのミラーセット内の他のドライブでの one 不幸なエラーによってダウンする可能性があります。完全に機能しています。このような障害が発生した場合、他に何が起こっても、一部のデータが失われます。
ZFSプールの容量を増やす通常の方法は、ドライブをインプレースに交換し、プールを新しいドライブに再シルバー化してから、古いドライブを物理的に削除することです。それはもう使われていません。通常、古いドライブと新しいドライブの両方を接続した状態でzpool replaceを使用して、プロセス全体で必要な冗長性レベルを維持する必要があります。通常の代替方法は、プール内の既存のvdevと同じ冗長レベルのvdevを追加することです。繰り返しになりますが、ZFSはストライプセットの一部の削除をサポートしておらず、プールは厳密にストライプvdevで構成されているため、一度追加したvdevを削除することはできません。 ZFSの初心者の多くはこの罠に陥ります。使用する正確なコマンドに注意を払わないと、混乱しやすくなります。
ZFS resilversがどのように機能するかにより、再シルバー化は関連するドライブにとって非常に苦痛です。従来のRAIDリシルバーは通常、ほとんどがシーケンシャルであり、ユーザーアクティビティからのランダムI/Oが少量散在していますが、ZFSリシルバーは、ユーザーアクティビティからのランダムI/Oが散在するほぼ完全なランダムI/Oです。ミラーセットは、その生涯を通じてほぼ同じ活動を見てきました。一方のドライブが限界であるか、または死んでいる場合でも、もう一方のドライブもせいぜい限界である可能性があります。何日にもわたって再銀化の試練に苦しむことは、非常に簡単にそれを端から押し出すかもしれません。 （個人的な経験に基づいて、6 TBのデータを復元するには、約1週間の復元プロセスを見ていると思います。すべてのノブを回しても 最大11 、純粋なシーケンシャルスループットに基づく-これは、ZFSのディスク上のフォーマットと再シルバー化戦略を考えると完全に非現実的です-あなたは少なくとも約17時間を見ています私の最善の推測は、6 TB resilverをその2倍未満、つまり1日半の完全なドライブにまで下げる方法はないだろうということです。乱用。）
また、そのようなドライブが実現すると仮定すると、2x24TBまたは2x12TBのミラー構成についても非常に深刻な疑問があります。現在のドライブサイズでは、すでに物理学の限界を少し押し上げています（しゃれは意図していません）。 [〜＃〜] ure [〜＃〜] の観点から、ドライブの信頼性を仮定すると、今日と同じままです（読み取りビットあたり、10 ^ -14から10 ^ -15のセクターエラー、ここではメーカーのデータシートで永遠にホバリングしています）、統計的には、少なくとも1つのエラーが発生しないと12TBドライブの完全な読み取りを行うことはできません（12 TBは約9×10です） ^ 13ビット、これは10 ^ 14にうまく丸められます。これを24にプッシュするまでにTBドライブ、統計的には少なくともにヒットします1回のフルリードパスで1つまたは2つのフルセクターエラー（約2 * 10 ^ 14ビットを読み取っているため）。10^ -15UREドライブを使用している場合でも、それほど購入することはありません（その場合は半分の読み取りパスではなく、5つの読み取りパスを確認します。これはもちろん統計と仕様です。実際には、読み取りエラーはクラスター化する傾向があり、ドライブは多くの、多くのフルに問題のないサービスを提供する可能性があります。その前に読み取り、ある時点で、左右中央にエラーをスローし始めます。
ほとんどの非サーバースピナーは1〜3年間しか保証されていないことを考えると、それよりもずっと長く機能し続けるセットは期待していませんが、あなたの計画では、それらが置き換えられる前に少なくとも6年間機能し続けることが求められています。サーバースピナーでさえ、通常は5年間しか保証されませんが、通常は5年間の24時間365日の運用が保証されます。私の個人的な経験では、SeagateのConstellation ESシリーズなどのハイエンドの消費者向けドライブは、ゴーストをあきらめてデータ天国に行く前に、ほぼこのレベルの義務を果たすことができます。 （個人的な逸話：a 1 TB Constellation ES.2それがおかしな行動を開始するまでに、私は4年9-10か月のようなものを抱えていましたが、失敗することはありませんでした。 ）
一般に、スピナーサイズが3〜4 TBマーク、またはより重要なデータの場合はそれ以下になると、ZFSを実行する多くの人が2倍の冗長性を使用することを考慮してください。これには正当な理由があります：- ストレージデバイスの障害 そしてそれ 驚くべき頻度で発生します 。ZFSの場合、生のデータを返す以外の何かが必要な場合は、はるかに高価なデータ回復サービスも検討しています。たまたまプラッターから読み取れるビットであり、ZFSプールをリモートで処理できるデータ回復ソフトウェアを私は知りません。ZFSがプールをインポートできない場合、最も実用的な答えは、多くの場合、失われたものと見なすことです。バックアップしなかったデータ 他の場所 。
タイトルの質問に答えるために、そしてTL; DR
FreeNAS/ZFSは私のストレージをこのように管理させてくれますか？
厳密に技術的な意味では、そうです。しかし、私は本当にはまったくお勧めしません。 あなたはハードウェアの運用範囲を過度に押し上げています私がそれを快適に感じるには、それを支持することは言うまでもありません。 （この回答は、質問しているファイルシステムに関係なく、ほとんど同じであることに注意してください。）