01
Normalizza byte, TB e TiB
Le etichette delle unità e il catalogo Tungsto utilizzano unità decimali: un TB corrisponde a 1,000,000,000,000 byte. Un TiB corrisponde a 1,099,511,627,776 byte. Lo stesso numero di byte appare quindi come un numero inferiore in TiB. Convertire dai byte di origine anziché applicare ripetutamente una percentuale arrotondata ed etichettare ogni colonna del foglio di lavoro con la propria unità.
Ad esempio, l'array del catalogo 12 × 16 TB contiene 192 TB grezzi prima della ridondanza, mentre 24 × 20 TB contiene 480 TB grezzi. Tali cifre escludono la coppia di avvio separata NVMe. Sono fatti di inventario, non affermazioni sulla capacità visibile o scrivibile dal filesystem.
Normalizza byte, TB e TiB| Fase | Input di calcolo | Output da conservare |
|---|
| Inventario | Conteggio × byte del disco partecipante più piccolo | Byte grezzi e TB decimali |
|---|
| Ridondanza | Topologia mirror o parità | Capacità approssimativa dell'array o del pool |
|---|
| Operazioni | Ricambi a caldo e politica di sostituzione | Capacità effettivamente assegnata ai vdev dati o all'array |
|---|
| Filesystem | Metadati, prenotazioni e proprietà correnti | Capacità scrivibile riportata |
|---|
| Applicazione | Snapshot, conservazione e margine di sicurezza | Capacità disponibile per i dati pianificati |
|---|
02
Modella la topologia reale, non una singola riga aggregata
Usa la dimensione del dispositivo partecipante più piccola quando i membri differiscono, a meno che l'implementazione selezionata non documenti diversamente; porzioni più grandi potrebbero rimanere inutilizzabili. Separa dispositivi di avvio, cache, log, spare e dati. Per ZFS, identifica ogni vdev di primo livello e la sua ridondanza. I dati sono distribuiti su vdev di primo livello, quindi una vdev non ridondante può rendere un pool altrimenti mirrorato vulnerabile a quel singolo dispositivo.
La semplice formula di parità approssima un gruppo RAIDZ come dispositivi dati per dimensione del dispositivo, ma l'allocazione effettiva dipende dalla dimensione del record, dalla geometria del settore e dal comportamento della parità. OpenZFS descrive quindi la sua proprietà di pool utilizzabile come euristica, non come promessa esatta.
03
Applicare una cascata di capacità
Inizia con i byte grezzi, sottrai la ridondanza e gli eventuali hot spare dedicati, poi leggi la proprietà disponibile del filesystem o pool creato. Da quel risultato, riserva lo spazio richiesto da policy, snapshot, comportamento copy-on-write, replica temporanea o lavoro di ripristino e crescita dell'applicazione. Non dare per scontati risparmi da compressione o deduplicazione; entrambi dipendono da dati e configurazione e possono scomparire da una previsione conservativa.
Mantieni due output: capacità teorica per confrontare i layout e capacità operativa per ammettere i dati. La seconda dovrebbe includere una soglia di allerta e una soglia di stop-ammissione scelte dall'operatore. Un filesystem che si riempie fino all'ultimo byte riportato può compromettere manutenzione e ripristino anche se l'aritmetica originariamente sembrava corretta.
04
Valida il pool creato prima di impegnare i dati
Dopo aver creato il layout selezionato, registra l'appartenenza dei dispositivi, la ridondanza, lo stato di salute e la capacità disponibile riportata dall'implementazione. Su ZFS, distingui le stime a livello di pool dalla disponibilità dei dataset perché quote, prenotazioni e parità possono farle differire. Il calcolatore di capacità TrueNAS è utile per pianificare la geometria ZFS, ma i suoi input devono comunque corrispondere ai dischi effettivi, ashift, dimensione dei record, dischi di riserva e politica di prenotazione.
Crea un record di accettazione prima della produzione: byte grezzi, diagramma del layout, valore calcolato, valore riportato, riserva, politica degli snapshot e destinazione del backup. Indaga su qualsiasi divario inspiegabile invece di cambiare unità finché i numeri non sembrano corrispondere.
05
Mantieni separate capacità e ripristino
Un valore utilizzabile più elevato non dimostra una progettazione più sicura. Indica i guasti dei dispositivi tollerati, il monitoraggio, la procedura per i ricambi, la policy di scrub o controllo di coerenza e la fonte di ripristino accanto al risultato della capacità. La ridondanza RAID e ZFS rimane all'interno di un singolo chassis; non protegge da cancellazione, compromissione o perdita del server.
Il risultato atteso è un foglio di lavoro di capacità riproducibile che un altro operatore può ricalcolare dai byte del dispositivo e dalla topologia. Usa il calcolatore per una rosa ristretta, poi sostituisci la sua stima con le proprietà osservate dal pool distribuito prima di offrire capacità applicativa.
Risposte dirette
Domande su questa guida
Perché un server raw 192 TB mostra meno TiB?
TB e TiB dividono gli stessi byte per dimensioni di unità diverse, e RAID più i livelli del filesystem riducono ulteriormente il risultato. Conserva i byte come valore di origine ed etichetta ogni conversione.
La compressione prevista dovrebbe essere aggiunta alla capacità utilizzabile?
Non come capacità garantita. La compressione dipende dai dati e dalle impostazioni. Tratta qualsiasi riduzione misurata come uno scenario separato mantenendo un piano di ammissione non compresso.