Calcolatore Ceph

Quanto spazio utile dà Ceph con replica 3

Dividendo il grezzo per tre si ottiene lo spazio teorico. Il numero che conta è un altro: quanti dati puoi scrivere in modo che, dopo il guasto peggiore che vuoi reggere e il recupero, l'OSD più pieno resti sotto la soglia nearfull (85% di default). Il calcolatore lo chiama capacità consigliata e lo stima su un collocamento ideale: i dati si distribuiscono fra i domini in proporzione alla capacità, con una copia o un frammento per dominio. Lo squilibrio fra gli OSD è un'ipotesi esplicita, il 5% di default, che puoi modificare.

L   = (soglia - quota block.db) / (1 + squilibrio)
a_d = capacità del dominio d × L, in ordine decrescente
X*  = min per j da 0 a w-1 di S_j / (1 - j/w)
capacità logica = X* / amplificazione

L è il riempimento massimo ammesso per un OSD, al netto di block.db e dello squilibrio; a_d è lo spazio utilizzabile del dominio d; w è il numero di copie in replica, oppure k+m in erasure coding; S_j è la somma degli a_d esclusi i j domini più grandi; l'amplificazione è size in replica e (k+m)/k in erasure coding. Un dominio non può contenere più di X*/w, perché ogni oggetto ha al massimo una copia o un frammento per dominio: da questo vincolo nascono sia lo spazio bloccato dai domini diseguali sia la riserva per il guasto.

Esempio svolto: 3 nodi con 4 OSD da 3,84 TB, replica 3, failure domain host, block.db su un device dedicato. Il grezzo è 46,08 TB, cioè 41,91 TiB, e il teorico 13,97 TiB. Con tre nodi, dopo la perdita di un nodo la terza copia non si ricostruisce, perché servirebbe un quarto dominio: il guasto da reggere diventa quindi la perdita di un OSD. I dati di quell'OSD si ricostruiscono sugli altri tre OSD dello stesso nodo, il cui riempimento cresce di un terzo; perché restino sotto l'85% si possono scrivere 8,91 TiB senza squilibrio, 8,48 TiB con il 5%.

Accanto alla capacità consigliata il calcolatore mostra altri due valori. Il limite di ricostruzione, calcolato sulla soglia backfillfull (90%): oltre questo valore, dopo il guasto il backfill si ferma e la ricostruzione non si completa. Il limite di scrittura, calcolato sulla soglia full (95%): oltre questo valore Ceph blocca le scritture.

Replica o erasure coding

La replica 3 conserva tre copie intere di ogni oggetto: amplificazione 3, min_size 2, letture da una copia sola. L'erasure coding k+m divide ogni oggetto in k frammenti di dati e m di parità: l'amplificazione scende a (k+m)/k, cioè 1,5 per un 4+2, in cambio di più CPU e più latenza. Per usare un pool EC con RBD o CephFS serve allow_ec_overwrites, che abilita le scritture parziali.

Servono almeno k+m domini, e la documentazione di Ceph consiglia di averne uno in più per poter ricostruire dopo un guasto. Con EC 4+2 su 6 host, dopo la perdita di un host i dati restano leggibili ma i frammenti mancanti non si ricostruiscono; con 7 host sì.

Esempio svolto: 7 nodi con 4 HDD da 16 TB, la perdita di un nodo da reggere, nessuno squilibrio fra gli OSD e block.db sugli stessi dischi al 2% (il valore predefinito). In replica 3 si possono scrivere 96,62 TiB, in EC 4+2 193,25 TiB: il doppio, sugli stessi dischi.

Cosa succede quando si guasta un nodo

Per ogni guasto il calcolatore risponde a tre domande. I dati sono salvi? Sì se il guasto colpisce meno domini di quante sono le copie (in replica) o al più m domini (in erasure coding); oltre, dipende da come i PG sono distribuiti, e il calcolatore scrive «non garantiti». L'I/O continua? Sì se ogni PG conserva almeno min_size copie o frammenti, i MON restano in quorum e il peering si conclude. La ridondanza torna completa? Solo se restano almeno w domini e se, dopo il recupero, l'OSD più pieno resta sotto backfillfull, così che il backfill possa completarsi.

Il guasto peggiore, quello che determina la capacità consigliata, si cerca fra tutte le combinazioni dei guasti da reggere, non solo togliendo il nodo più grande: con domini diseguali il caso peggiore può essere un altro.

Con 3 nodi in replica 3, dopo la perdita di un nodo i dati restano con due copie e l'I/O continua grazie a min_size 2, ma la terza copia non si ricostruisce finché il nodo non torna. In ogni caso Ceph non ricostruisce subito: si accorge che un OSD non risponde in circa 20 secondi (osd_heartbeat_grace) e lo segna out dopo 10 minuti (mon_osd_down_out_interval). Un rack intero non viene segnato out in automatico (mon_osd_down_out_subtree_limit vale rack): in quel caso il recupero lo avvii tu.

Come dimensionare block.db e WAL

Con gli OSD su HDD, block.db su NVMe accelera metadati e scritture piccole. Le regole pubblicate non coincidono:

Il 10% di pveceph è lo spazio che alloca quando non indichi una dimensione e Ceph non ne ha una configurata: non misura il fabbisogno. Il calcolatore consiglia il 2% per RBD e il 4% per CephFS, RGW e carichi misti, cioè il valore più alto della raccomandazione ufficiale di Squid e Tentacle per ciascun carico. È una scelta del calcolatore: la documentazione di sviluppo chiede almeno il 2,5%, e se vuoi seguirla basta aggiungere un margine nella scheda DB/WAL.

Esempio svolto: con 12 OSD da 16 TB per nodo e carico RBD, il 2% fa 320 GB di block.db per OSD, 3,84 TB per nodo prima di ogni margine. Un NVMe da 3,84 TB basterebbe solo se tutta la sua capacità fosse allocabile. Le raccomandazioni hardware di Ceph indicano fino a 10 OSD per NVMe, 15 con un NVMe PCIe Gen4 o successivo: 12 OSD stanno su un solo device solo se è Gen4. E se un device si guasta, si fermano insieme tutti gli OSD che serve: con un device sono tutti i 12 OSD del nodo, con due device 6. La scheda DB/WAL del calcolatore simula proprio questo guasto.

Il WAL sta sul device del DB e usa il suo spazio, quindi non va contato due volte; ha senso separarlo solo su un device più veloce di quello del DB. I livelli di RocksDB (1, 8, 64 e 512 GiB, con use_some_extra) spiegano come cresce il DB ma non sono gradini di dimensionamento: i vecchi valori da 3, 30 e 300 GB non valgono più come regola. Quando block.db si riempie, i metadati in eccesso finiscono sul disco lento e Ceph segnala BLUEFS_SPILLOVER.

SSD e NVMe: cosa accelera davvero

• DB e WAL su NVMe: accelerano metadati e scritture piccole; non sono una cache per i dati.
• Pool per device class: un pool NVMe per i dischi delle VM e uno HDD per backup e dati freddi; ogni pool usa solo i dischi della sua classe, e il calcolatore calcola le classi separatamente.
• Primary affinity: fra gli OSD di un PG fa scegliere come primary quello su SSD, se il PG ne ha uno; le letture vanno lì, ma le scritture aspettano comunque tutte le copie.
• Cache tiering: deprecato da Ceph Reef, perché da tempo non ha un manutentore e potrebbe essere rimosso; in un cluster nuovo meglio non usarlo.

RAM, CPU e rete per nodo

Il punto di partenza per la RAM è osd_memory_target, 4 GiB per OSD. È un obiettivo, non un tetto: Ceph libera memoria in best effort e un OSD può superarlo, quindi il calcolatore aggiunge un 20%. La documentazione di Proxmox VE indica invece 8 GiB per OSD. Con 12 OSD per nodo servono 57,6 GiB con la prima regola e 96 GiB con la seconda, più MON (4 GiB), MGR (2 GiB), MDS se usi CephFS (5 GiB), sistema operativo e VM.

Per la CPU il calcolatore usa come punto di partenza da 1 a 3 thread per OSD su HDD, da 2 a 4 su SSD SATA e da 4 a 6 su NVMe, più un thread per ogni servizio (MON, MGR, MDS). Sono thread, non core fisici.

Proxmox VE raccomanda almeno 10 Gb/s dedicati a Ceph, 25 Gb/s o più con dischi NVMe, e 40 o 100 Gb/s per sfruttare NVMe veloci, con Corosync su una rete separata. Ogni GB scritto da un client genera fra gli OSD altri GB di traffico: size meno 1 in replica, (k+m-1)/k in erasure coding per le scritture complete, cioè 2 GB con la replica 3 e 1,25 GB con EC 4+2. Le scritture parziali in erasure coding possono generarne di più.

Quanto dura un recupero

Il tempo di trasferimento è il più alto fra quattro tempi, uno per ogni possibile collo di bottiglia: i dischi che ricevono i dati, la rete dei nodi che li ricevono, i dischi superstiti (che leggono e scrivono insieme) e la rete del cluster nel suo complesso.

tempo = max( ricevuto dall'OSD più carico / banda OSD,
             ricevuto dal nodo più carico / banda di rete,
             V × (fattore lettura + 1) / (OSD superstiti × banda OSD),
             V × fattore rete / (nodi superstiti × banda di rete) )

V è il volume da ricostruire; i fattori valgono 1 in replica e k in erasure coding, perché il primary legge k frammenti per ricostruirne uno. Come banda di un OSD il calcolatore usa i valori predefiniti di mClock (osd_mclock_max_sequential_bandwidth_hdd e _ssd): 150 MiB/s per gli HDD, 1.200 MiB/s per SSD e NVMe. Sono parametri di configurazione, non misure dei dischi: nei parametri avanzati puoi inserire una tua misura. Lo scenario prudente usa metà di questa banda e la rete al 50%, quello ottimistico tutta la banda e la rete al 90%. È una stima, non una velocità garantita: con le tue misure il numero cambia.

Esempio svolto: 5 nodi con 6 NVMe da 7,68 TB e rete a 25 Gb/s, cluster riempito fino alla capacità consigliata, nessuno squilibrio fra gli OSD, block.db sugli stessi dischi al 2% e la perdita di un nodo. Da ricostruire ci sono 30,6 TB: il trasferimento richiede da 45 a 82 minuti e il collo di bottiglia è la rete. A questo tempo si aggiungono il rilevamento del guasto e, con i valori predefiniti, i 10 minuti prima che gli OSD vengano segnati out.

Come calcoliamo: formule e fonti

Modello 1.2.0 del 19 ottobre 2026, per Ceph Squid 19.2 e Tentacle 20.2; Proxmox VE 9.2 installa di default Tentacle 20.2.1. Il motore del calcolatore è confrontato con un'implementazione di riferimento indipendente su 22 casi di capacità da 3 a 128 nodi, scenari di guasto, stime di recupero, PG e block.db, e la ricerca del guasto peggiore con l'enumerazione di tutte le combinazioni.

La versione 1 non copre: più schemi di protezione sulla stessa classe di dischi, pool su più classi, regole CRUSH personalizzate oltre a OSD, host e rack, stretch cluster, compressione, amplificazione degli oggetti piccoli e prestazioni dei client.

• Ceph, pool, size e min_size
• Ceph, erasure coding
• Ceph, soglie nearfull, backfillfull e full
• Ceph, quando un OSD va out
• Ceph, BlueStore e block.db (Tentacle)
• Red Hat Ceph Storage 8, BlueStore
• Ceph, raccomandazioni hardware
• Ceph, mClock e banda sequenziale
• Ceph, cache tiering deprecato
• Proxmox VE, Ceph iperconvergente