ZFSプール容量計算機

容量計算

• Raw容量 = Σ(VDEV毎の本数 × ディスク容量)
• Usable容量 = Raw容量 × 実効効率(RAIDZ方式ごとのデータ本数/全本数の比率) × パディング係数(recordsize/ashift/推奨幅から算出)
• 実使用可能容量 = Usable容量 − メタデータオーバーヘッド − 予約領域(Slop Space) − スナップショット見積り
• 圧縮考慮(論理) = 実使用可能容量 × Compression比
• 推奨運用上限(圧縮考慮後の目安) = 圧縮考慮(論理) × Dedup比 × 目標プール使用率

性能推定

• ランダムIOPS: 1VDEVあたり(RAIDZ系はディスク1本分、Mirrorは Read=本数倍/Write=1本分)を算出し、 それをVDEV数ぶん合算したPool全体の値を表示(VDEV数が1の場合は1VDEV分と同じ数値になる)
• シーケンシャル速度: パリティ分を除いたデータ本数ぶん並列化(Mirrorは Read のみ本数倍)、これもPool全体(全VDEV合算)の値
• ARCヒット率 = 1 − (1 − min(1, ARCサイズ / ワーキングセット))²(収穫逓減カーブによる経験的近似)
• 推奨RAM = max(実効容量[TB] × 1GB/TB, ARC目標, DedupテーブルRAM) + OS用8GB
• 推奨CPUコア数 = 基本4コア + (圧縮有効:+2) + (Dedup有効:+4) + シーケンシャル速度に応じた追加分
• ディスクの性能値(IOPS/MBps/レイテンシ)は特定機種カタログではなく、媒体種別(HDD/SATA SSD/SAS SSD/NVMe)ごとの代表値プリセットを使用(詳細設定で個別に上書き可能)
• SLOGは同期書込レイテンシの算出にのみ用いる(選択したディスク種別のレイテンシ + プロトコルオーバーヘッド)。 「ミラー(2本)」を選ぶとベイ構成にも2本分反映されるが、性能計算そのものはミラーでも1本分のレイテンシとして扱う(冗長化は可用性のための構成であり速度は変わらないため)
• L2ARCは容量(本数 × 1本あたり容量)がヒット率算出に使われる。ディスク種別は物理構成の記録用で、 L2ARCはZFSの仕様上ミラー(冗長化)の概念を持たない(消失してもプールへの影響はなくキャッシュとして再構築されるため)
• IOPS⇄MB/s相互換算(参考値): ランダムIOPSは4Kブロック基準、シーケンシャル速度はrecordsize基準で単純換算しているだけで、 実際のアクセスパターン次第でズレる参考値です

ARC/L2ARCの効果(キャッシュ効果モデル)

以下はPythonバックエンドには存在しない、このフリー版独自の追加モデルです(前提を明記した上で参考値として掲載しています)。

• ARC/L2ARCにヒットしたリクエストはバックエンドディスクのIOPSを消費しない、という前提で、 実効ランダムRead IOPS = バックエンドディスクIOPS ÷ ミス率(= 1 − ARCヒット率 − L2ARCヒット率)として近似
• ミス率が0%に近づくと数値が発散するため、下限を0.1%としてクランプしています
• 平均レイテンシ = ARCヒット率 × ARC相当レイテンシ(0.02ms、RAM速度の目安) + L2ARCヒット率 × 選択したL2ARCディスクのレイテンシ + ミス率 × プールディスクのレイテンシ、で加重平均
• ワーキングセット(実効容量 × ワークロードごとのワーキングセット比率)がARC/L2ARC容量に対して 大きいほどヒット率が低くなり、効果も小さく表示されます(これは意図した挙動です)
• 「コールドキャッシュ⇄フルヒット」の3点比較は、ARCヒット率0%(起動直後などキャッシュが 温まっていない状態)・現在の設定(ARC/L2ARCサイズから推定した定常状態のヒット率)・ ARCヒット率100%(ワーキングセットを完全にカバーできた場合の理論上限)の3シナリオを 同じ式に代入して並べただけで、実際の遷移時間(キャッシュが温まるまでの時間)は計算していません

容量成長予測

• 線形モデル: 予測使用量(n日後) = 現在使用量 + 日次増加量 × n
• 複利モデル: 予測使用量(n日後) = 現在使用量 × (1 + 年間成長率)^(n / 365)
• スナップショット容量は母体データと同じ成長率でスケールさせて加算
• 閾値到達日数は、予測使用量が「圧縮考慮後の目安 × 目標プール使用率」に達するまでの日数を逆算
• 増設目安日 = 閾値到達日 − 調達リードタイム(発注から搬入までの見込み日数)