Bruikbare opslag na RAID

01

Normaliseer bytes, TB en TiB

Schijflabels en de Tungsto-catalogus gebruiken decimale eenheden: één TB is 1,000,000,000,000 bytes. Eén TiB is 1,099,511,627,776 bytes. Hetzelfde aantal bytes verschijnt daarom als een kleiner getal in TiB. Reken om vanuit de bronbytes in plaats van herhaaldelijk een afgerond percentage toe te passen, en label elke werkbladkolom met zijn eenheid.

De 12 × 16 TB catalogusarray bevat bijvoorbeeld 192 TB ruw vóór redundantie, terwijl 24 × 20 TB 480 TB ruw bevat. Die cijfers sluiten het afzonderlijke NVMe opstartpaar uit. Het zijn inventarisfeiten, geen claims over bestandssysteem-zichtbare of beschrijfbare capaciteit.

02

Modelleer de echte topologie, niet één geaggregeerde rij

Gebruik de kleinste deelnemende apparaatgrootte wanneer leden verschillen, tenzij de geselecteerde implementatie anders documenteert; grotere delen kunnen onbruikbaar blijven. Scheid boot-, cache-, log-, reserve- en data-apparaten. Identificeer voor ZFS elke top-level vdev en zijn redundantie. Gegevens worden gestript over top-level vdevs, dus één niet-redundante vdev kan een anders gespiegelde pool kwetsbaar maken voor dat ene apparaat.

De eenvoudige pariteitsformule benadert een RAIDZ-groep als dataschijven maal schijfgrootte, maar de werkelijke toewijzing hangt af van recordgrootte, sectorgeometrie en pariteitsgedrag. OpenZFS beschrijft zijn bruikbare pool-eigenschap daarom als een heuristiek, niet als een exacte belofte.

• OpenZFS eigenschappen van poolcapaciteit ↗

03

Pas een capaciteitswaterval toe

Begin met ruwe bytes, trek redundantie en eventuele toegewijde hot spares af en lees vervolgens de beschikbare eigenschap van het aangemaakte bestandssysteem of de pool. Reserveer van dat resultaat de ruimte die vereist is door beleid, snapshots, copy-on-write-gedrag, tijdelijke replicatie- of herstelwerkzaamheden en toepassingsgroei. Ga niet uit van compressie- of deduplicatiewinst; beide zijn afhankelijk van gegevens en configuratie en kunnen uit een conservatieve prognose verdwijnen.

Houd twee uitvoerwaarden bij: theoretische capaciteit voor het vergelijken van lay-outs en operationele capaciteit voor het toelaten van gegevens. De tweede moet een waarschuwingsdrempel en een stop-toelatingsdrempel bevatten die door de operator zijn gekozen. Een bestandssysteem dat tot zijn laatst gerapporteerde byte vol raakt, kan onderhoud en herstel belemmeren, zelfs als de berekening oorspronkelijk correct leek.

04

Valideer de aangemaakte pool voordat u gegevens toevertrouwt

Leg na het aanmaken van de geselecteerde indeling het apparaatlidmaatschap, de redundantie, de gezondheid en de gerapporteerde beschikbare capaciteit van de implementatie vast. Maak op ZFS onderscheid tussen schattingen op poolniveau en beschikbaarheid van datasets, omdat quota's, reserveringen en pariteit deze kunnen laten verschillen. De TrueNAS-capaciteitscalculator is nuttig voor het plannen van de ZFS-geometrie, maar de invoer moet nog steeds overeenkomen met de werkelijke schijven, ashift, recordgrootte, reserves en het reserveringsbeleid.

Maak een acceptatierecord vóór productie: ruwe bytes, lay-outdiagram, berekende waarde, gerapporteerde waarde, reserve, snapshotbeleid en back-upbestemming. Onderzoek elke onverklaarde kloof in plaats van eenheden te wijzigen totdat de cijfers lijken te kloppen.

05

Houd capaciteit en herstel gescheiden

Een groter bruikbaar cijfer bewijst geen veiliger ontwerp. Vermeld getolereerde apparaatstoringen, monitoring, reserveprocedure, scrub- of consistentiecontrolebeleid en herstelbron naast het capaciteitsresultaat. RAID en ZFS redundantie blijven binnen één chassis; ze beschermen niet tegen verwijdering, compromittering of verlies van de server.

Het verwachte resultaat is een reproduceerbaar capaciteitswerkblad dat een andere operator kan herberekenen op basis van apparaatbytes en topologie. Gebruik de calculator voor een shortlist en vervang vervolgens de schatting door waargenomen eigenschappen van de ingezette pool voordat u applicatiecapaciteit aanbiedt.