01
Bytes, TB und TiB normalisieren
Laufwerksbezeichnungen und der Tungsto-Katalog verwenden Dezimaleinheiten: Ein TB entspricht 1,000,000,000,000 Bytes. Ein TiB entspricht 1,099,511,627,776 Bytes. Dieselbe Byte-Anzahl erscheint daher als kleinere Zahl in TiB. Rechnen Sie von den Quell-Bytes um, statt wiederholt einen gerundeten Prozentsatz anzuwenden, und beschriften Sie jede Arbeitsblattspalte mit ihrer Einheit.
Zum Beispiel enthält das 12 × 16 TB-Katalog-Array 192 TB roh vor Redundanz, während 24 × 20 TB 480 TB roh enthält. Diese Zahlen schließen das separate NVMe-Boot-Paar aus. Es handelt sich um Bestandsfakten, nicht um Angaben zur dateisystemsichtbaren oder beschreibbaren Kapazität.
Bytes, TB und TiB normalisieren| Stufe | Berechnungseingabe | Auszugebende Ausgabe |
|---|
| Bestand | Anzahl × kleinste teilnehmende Laufwerksbytes | Rohe Bytes und dezimales TB |
|---|
| Redundanz | Spiegel- oder Paritätstopologie | Ungefähre Array- oder Pool-Kapazität |
|---|
| Betrieb | Hot-Spares und Austauschrichtlinie | Tatsächlich den Daten-vdevs oder dem Array zugewiesene Kapazität |
|---|
| Dateisystem | Metadaten, Reservierungen und aktuelle Eigenschaften | Gemeldete beschreibbare Kapazität |
|---|
| Anwendung | Snapshots, Aufbewahrung und Sicherheitsreserve | Für geplante Daten verfügbare Kapazität |
|---|
02
Modellieren Sie die reale Topologie, nicht eine aggregierte Zeile
Verwenden Sie die kleinste teilnehmende Gerätegröße, wenn Mitglieder unterschiedlich sind, es sei denn, die gewählte Implementierung dokumentiert etwas anderes; größere Teile können ungenutzt bleiben. Trennen Sie Boot-, Cache-, Protokoll-, Ersatz- und Datengeräte. Identifizieren Sie für ZFS jedes Top-Level-vdev und seine Redundanz. Daten werden über Top-Level-vdevs gestreift, sodass ein nicht redundantes vdev einen ansonsten gespiegelten Pool anfällig für dieses einzelne Gerät machen kann.
Die einfache Paritätsformel nähert eine RAIDZ-Gruppe als Daten-Devices mal Device-Größe an, aber die tatsächliche Zuweisung hängt von Datensatzgröße, Sektorgeometrie und Paritätsverhalten ab. OpenZFS beschreibt daher seine nutzbare Pool-Eigenschaft als Heuristik, nicht als exaktes Versprechen.
03
Wenden Sie einen Kapazitäts-Wasserfall an
Beginnen Sie mit rohen Bytes, ziehen Sie Redundanz und dedizierte Hot-Spares ab und lesen Sie dann die verfügbare Eigenschaft des erstellten Dateisystems oder Pools. Reservieren Sie von diesem Ergebnis den durch Richtlinien, Snapshots, Copy-on-Write-Verhalten, temporäre Replikation oder Wiederherstellungsarbeiten und Anwendungswachstum benötigten Speicherplatz. Gehen Sie nicht von Komprimierungs- oder Deduplizierungseinsparungen aus; beide hängen von Daten und Konfiguration ab und können aus einer konservativen Prognose verschwinden.
Behalten Sie zwei Ausgaben bei: theoretische Kapazität zum Vergleichen von Layouts und operative Kapazität zum Aufnehmen von Daten. Die zweite sollte eine vom Operator gewählte Warnschwelle und eine Stopp-Aufnahme-Schwelle enthalten. Ein Dateisystem, das bis zum letzten gemeldeten Byte gefüllt ist, kann Wartung und Wiederherstellung beeinträchtigen, selbst wenn die Arithmetik ursprünglich korrekt aussah.
04
Erstellten Pool vor der Datennutzung validieren
Nach dem Erstellen des gewählten Layouts erfassen Sie Gerätezugehörigkeit, Redundanz, Zustand und die vom System gemeldete verfügbare Kapazität. Unterscheiden Sie auf ZFS zwischen Schätzungen auf Poolebene und der Verfügbarkeit von Datasets, da Quoten, Reservierungen und Parität diese unterschiedlich machen können. Der TrueNAS-Kapazitätsrechner ist nützlich für die Planung der ZFS-Geometrie, aber seine Eingaben müssen den tatsächlichen Laufwerken, ashift, Datensatzgröße, Ersatzlaufwerken und Reservierungsrichtlinien entsprechen.
Erstellen Sie vor der Produktion einen Abnahmedatensatz: Rohbytes, Layoutdiagramm, berechneter Wert, gemeldeter Wert, Reserve, Snapshot-Richtlinie und Backup-Ziel. Untersuchen Sie jede unerklärte Lücke, anstatt Einheiten zu ändern, bis die Zahlen übereinzustimmen scheinen.
05
Halten Sie Kapazität und Wiederherstellung getrennt
Eine größere nutzbare Zahl beweist kein sichereres Design. Geben Sie tolerierte Geräteausfälle, Überwachung, Ersatzverfahren, Scrub- oder Konsistenzprüfungsrichtlinie und Wiederherstellungsquelle neben dem Kapazitätsergebnis an. RAID- und ZFS-Redundanz bleiben innerhalb eines Gehäuses; sie schützen nicht vor Löschung, Kompromittierung oder Verlust des Servers.
Das erwartete Ergebnis ist ein reproduzierbares Kapazitätsarbeitsblatt, das ein anderer Operator aus Gerätebytes und Topologie neu berechnen kann. Verwenden Sie den Rechner für eine Auswahlliste und ersetzen Sie dann seine Schätzung durch beobachtete Eigenschaften aus dem eingesetzten Pool, bevor Sie Anwendungskapazität anbieten.
Direkte Antworten
Fragen zu diesem Leitfaden
Warum zeigt ein 192 TB Raw-Server weniger TiB an?
TB und TiB teilen dieselben Bytes durch unterschiedliche Einheitengrößen, und RAID plus Dateisystemebenen reduzieren das Ergebnis weiter. Bewahren Sie Bytes als Quellwert auf und kennzeichnen Sie jede Umrechnung.
Sollte erwartete Komprimierung zur nutzbaren Kapazität hinzugerechnet werden?
Nicht als garantierte Kapazität. Die Komprimierung hängt von den Daten und Einstellungen ab. Behandeln Sie jede gemessene Reduzierung als separates Szenario, während Sie einen unkomprimierten Aufnahmeplan beibehalten.