Dienststatus & Verfügbarkeit Nur Krypto-Abrechnung · Keine KYC-Anmeldung

Betreiberhandbuch · 4 Min. Lesezeit

Nutzbarer Speicher nach RAID

Die Rohkapazität der Festplatte ist nur der Ausgangspunkt. Berechnen Sie die Redundanz in dezimalen TB, unterscheiden Sie TB von TiB und berücksichtigen Sie dann Ersatzlaufwerke, Dateisystem-Overhead, Snapshots und Wiederherstellungspuffer.

Verwenden Sie durchgängig dezimale Terabytes

Laufwerkshersteller und der Tungsto-Katalog verwenden dezimale Terabyte: Ein TB entspricht 1,000,000,000,000 Bytes. Betriebssysteme zeigen möglicherweise binäre Tebibytes an, die bei gleicher Byte-Anzahl kleinere Zahlenwerte ergeben. Dieser Rechner gibt dezimale TB aus und schließt Dateisystem-Overhead, Metadaten, Hot-Spares und das NVMe-Boot-Paar aus.

RAID Rechner

Schätzen Sie nutzbare dezimale TB.

Geschätzte nutzbare Kapazität160 TBVor dem Dateisystem-Overhead

Referenzkapazitäten

ArrayRohRAID 5RAID 6RAID 10
12 × 16 TB192 TB176 TB160 TB96 TB
24 × 20 TB480 TB460 TB440 TB240 TB

RAID 1 verwendet die Kapazität eines Laufwerks unabhängig von der Spiegelanzahl. RAID 5 benötigt mindestens drei Laufwerke, RAID 6 mindestens vier und RAID 10 eine gerade Anzahl von mindestens vier. Ungültige Layouts sollten abgelehnt und nicht angenähert werden.

Gehen Sie tiefer

Treffen Sie eine Entscheidung, die Sie überprüfen können.

4 Mindestanleitung

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
StufeBerechnungseingabeAuszugebende Ausgabe
BestandAnzahl × kleinste teilnehmende LaufwerksbytesRohe Bytes und dezimales TB
RedundanzSpiegel- oder ParitätstopologieUngefähre Array- oder Pool-Kapazität
BetriebHot-Spares und AustauschrichtlinieTatsächlich den Daten-vdevs oder dem Array zugewiesene Kapazität
DateisystemMetadaten, Reservierungen und aktuelle EigenschaftenGemeldete beschreibbare Kapazität
AnwendungSnapshots, Aufbewahrung und SicherheitsreserveFür geplante Daten verfügbare Kapazität

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.

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.

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.

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.