RAID 後の使用可能なストレージ

01

バイト、TB、TiBを正規化する

ドライブの表示とTungstoのカタログは十進単位を使用します。1 TBは1,000,000,000,000バイトです。1 TiBは1,099,511,627,776バイトです。したがって、同じバイト数でもTiBで表すと数値は小さくなります。丸めた比率を繰り返し適用するのではなく、元のバイト数から変換し、ワークシートの各列に単位を明記してください。

たとえば、12 × 16 TBカタログアレイには冗長性前の生の192 TBが含まれ、24 × 20 TBには生の480 TBが含まれます。これらの数値には個別のNVMeブートペアは含まれません。これらは在庫の事実であり、ファイルシステムで表示可能または書き込み可能な容量に関する主張ではありません。

02

実際のトポロジーをモデル化し、1つの集計行にしない

メンバーが異なる場合は、選択した実装で別途文書化されていない限り、最小の参加デバイスサイズを使用してください。大きい部分は使用できないままになる場合があります。ブート、キャッシュ、ログ、スペア、データデバイスを分離してください。ZFSの場合、すべてのトップレベルvdevとその冗長性を特定してください。データはトップレベルvdev全体にストライプされるため、冗長性のないvdevが1つあると、それ以外はミラーリングされたプールがその単一デバイスに対して脆弱になる可能性があります。

単純なパリティ式は RAIDZ グループをデータデバイス数×デバイスサイズとして近似しますが、実際の割り当てはレコードサイズ、セクタジオメトリ、パリティ動作に依存します。したがって OpenZFS は、その使用可能プール特性を正確な約束ではなくヒューリスティックとして説明しています。

• ZFSプール容量プロパティを開く↗

03

容量ウォーターフォールを適用する

生バイトから始め、冗長性と専用ホットスペアを差し引き、作成されたファイルシステムまたはプール自体の利用可能プロパティを読み取ります。その結果から、ポリシー、スナップショット、コピーオンライト動作、一時的なレプリケーションまたはリストア作業、アプリケーションの成長に必要なスペースを確保します。圧縮や重複排除の節約を想定しないでください。どちらもデータと構成に依存し、保守的な予測から消える可能性があります。

2つの出力を保持してください。レイアウト比較のための理論容量と、データを受け入れるための運用容量です。後者には、オペレーターが選択したアラート閾値と受付停止閾値を含める必要があります。最後に報告されたバイトまで満杯になるファイルシステムは、当初の計算が正しく見えても、メンテナンスとリカバリを妨げる可能性があります。

04

データをコミットする前に作成されたプールを検証する

選択したレイアウトを作成した後、デバイスのメンバーシップ、冗長性、健全性、および実装が報告する利用可能な容量を記録します。ZFSでは、クォータ、予約、パリティによって異なる可能性があるため、プールレベルの見積もりとデータセットの可用性を区別してください。TrueNAS容量計算機はZFSジオメトリの計画に役立ちますが、その入力は実際のドライブ、ashift、レコードサイズ、スペア、予約ポリシーと一致する必要があります。

本番前に受け入れ記録を作成します：生バイト、レイアウト図、計算値、報告値、予備、スナップショットポリシー、バックアップ先。数字が一致するように見えるまで単位を変更するのではなく、説明のつかないギャップを調査してください。

05

容量とリカバリを分離する

使用可能な数値が大きいからといって、より安全な設計であるとは限りません。許容されるデバイス障害、監視、スペア手順、スクラブまたは整合性チェックポリシー、復元ソースを容量結果とともに明記してください。RAIDとZFSの冗長性は1つのシャーシ内に留まり、削除、侵害、サーバーの損失からは保護されません。

期待される結果は、別のオペレーターがデバイスのバイト数とトポロジーから再計算できる再現可能な容量ワークシートです。計算機を候補の絞り込みに使用し、アプリケーション容量を提供する前に、その推定値を展開されたプールの観測された特性に置き換えてください。