Storage distribuito, software-defined, che sopravvive alla morte di un intero nodo senza fermarsi. La base hyper-converged di Proxmox VE: niente più SAN dedicata, i dischi di ogni nodo diventano un unico pool condiviso.
"Ho tolto due dischi da host diversi nello stesso momento" — la frase che ti insegna cosa significa davvero un dominio di failure a livello host, di solito nel modo più doloroso possibile.
Non è "un RAID via rete": è un sistema di storage che distribuisce dati su decine di dischi e nodi diversi, senza un punto centrale che decide dove va cosa.
Ceph trasforma un gruppo di server con dischi locali "normali" in un unico pool di storage distribuito, senza bisogno di una SAN proprietaria dedicata. È self-healing: se un disco o un intero nodo muore, il cluster si accorge da solo dei dati "sotto-replicati" e li ricopia altrove automaticamente, senza intervento manuale immediato.
| Modalità di accesso | Cos'è | Uso tipico |
|---|---|---|
| RBD (RADOS Block Device) | Disco a blocchi distribuito | Dischi virtuali delle VM — esattamente quello che usa Proxmox VE (cap. 5-6) |
| CephFS | Filesystem POSIX distribuito | Storage file condiviso tra più nodi/container (cap. 7) |
| RGW (RADOS Gateway) | Object storage compatibile S3/Swift | Backup, archiviazione, applicazioni cloud-native (cap. 8) |
Un sistema di storage tradizionale spesso ha un "capo" che tiene il registro di dove sta ogni file (un metadata server centrale, un single point of failure e collo di bottiglia). Ceph fa una cosa diversa e più elegante: usa un algoritmo chiamato CRUSH (cap. 3) che permette a qualsiasi client di calcolare da solo, matematicamente, su quali dischi si trova un dato oggetto — senza dover chiedere a nessuno. È come se ogni bibliotecario di una rete di biblioteche sapesse a memoria la stessa formula per trovare qualsiasi libro in qualsiasi biblioteca della rete, senza dover telefonare a un archivio centrale.
Il concetto di "hyper-converged" non è esclusivo di Ceph: Nutanix (con il suo stack proprietario AOS/NDFS) e VMware vSAN risolvono lo stesso problema — calcolo e storage sugli stessi nodi, dati replicati automaticamente — ma con software closed-source, sviluppato e mantenuto da una singola azienda.
| Ceph | Nutanix AOS / VMware vSAN | |
|---|---|---|
| Licenza | Open source (LGPL) | Proprietario, licenza a pagamento |
| Hardware | Qualsiasi server/disco compatibile Linux | Spesso hardware certificato o appliance dedicate |
| Modalità di accesso | RBD, CephFS, RGW (cap. 1) | Tipicamente solo block/file per le VM dell'hypervisor supportato |
| Supporto commerciale | Community, o tramite Red Hat/IBM e altre terze parti | Incluso nel contratto col vendor |
| Flessibilità | Alta: usabile anche fuori da un solo hypervisor | Spesso legato a un ecosistema specifico (AHV/ESXi) |
Ceph è costruito su un motore di base, RADOS, e quattro tipi di demone che si dividono i compiti.
ceph orch ps
ceph mon stat
ceph osd treeIl cuore matematico di Ceph: come decide, senza una tabella centrale, esattamente su quali dischi mettere ogni singolo pezzo di dato.
Un oggetto (identificato dal suo nome dentro un pool) viene prima assegnato, tramite hash, a un Placement Group (PG) — una specie di "cassetto" logico condiviso da molti oggetti. Poi CRUSH (Controlled Replication Under Scalable Hashing) mappa quel PG su un insieme specifico di OSD reali, tenendo conto della topologia fisica del cluster: quali dischi stanno su quale nodo, quale nodo su quale rack.
Per default, CRUSH garantisce che le repliche di uno stesso oggetto finiscano su host diversi (il "failure domain" di default è host, configurabile anche a livello rack o datacenter). È il motivo per cui la morte di un intero nodo non fa perdere dati: nessuna delle repliche di un oggetto vive sullo stesso host di un'altra.
Qualsiasi client (incluso Proxmox stesso) può calcolare da solo, con la stessa formula CRUSH e la stessa mappa del cluster, esattamente dove leggere/scrivere — senza fare una query preventiva a un server "indice". Elimina un collo di bottiglia e un single point of failure che i sistemi di storage più vecchi avevano.
ceph osd tree # la mappa fisica: host, dischi, pesi
ceph osd crush rule dump # le regole di placement attive
ceph pg stat # quanti PG, in che statopg_num) va dimensionato in base al numero di OSD: troppo pochi PG limitano il parallelismo, troppi aumentano l'overhead di gestione. Ceph moderno include un PG autoscaler che regola questo valore da solo: lascialo attivo salvo motivi specifici per disabilitarlo.
Un pool è una partizione logica di oggetti, con la propria politica di ridondanza: repliche complete o erasure coding.
| Replica (default) | Erasure coding | |
|---|---|---|
| Come funziona | Copie identiche complete (tipicamente size=3) | Dati divisi in frammenti + parità, ricostruibili come RAID5/6 |
| Efficienza spazio | Bassa (3x lo spazio dei dati reali) | Alta (es. 4+2 usa solo 1,5x lo spazio) |
| Costo CPU/recovery | Basso | Più alto, specie in fase di recovery |
| Adatto a | RBD per VM (cap. 5-6): serve bassa latenza | RGW/CephFS per dati "freddi" (cap. 7-8) |
ceph osd pool create vm-storage 128
ceph osd pool set vm-storage size 3 # 3 copie totali (default consigliato)
ceph osd pool set vm-storage min_size 2 # sotto 2 copie disponibili, le scritture si bloccano
ceph osd pool application enable vm-storage rbdsize=3 e min_size=1, il cluster continuerebbe a scrivere anche con una sola copia disponibile: se quell'unico OSD muore prima che il rebalance ricrei le altre copie, i dati sono persi. min_size=2 è il compromesso standard: blocca le scritture (disponibilità ridotta temporaneamente) piuttosto che rischiare di scrivere dati che poi non potranno essere recuperati.
Quello che ti interessa davvero se il tuo obiettivo è storage per macchine virtuali: dischi virtuali distribuiti, con snapshot copy-on-write native.
Un'immagine RBD non vive su un singolo disco: è suddivisa in tanti piccoli oggetti (di default 4MB ciascuno) sparsi su decine di OSD diversi secondo CRUSH (cap. 3). È thin-provisioned (occupa spazio reale solo per i blocchi effettivamente scritti) e supporta snapshot copy-on-write istantanee, lo stesso principio visto per APFS/Btrfs/ZFS nelle altre guide di questo sito.
rbd create vm-storage/disco-vm-101 --size 32768 # 32 GiB
rbd ls vm-storage
rbd info vm-storage/disco-vm-101
rbd resize vm-storage/disco-vm-101 --size 65536 # ridimensiona a caldo
# Snapshot copy-on-write, istantanea
rbd snap create vm-storage/disco-vm-101@pre-update
rbd snap ls vm-storage/disco-vm-101
rbd snap rollback vm-storage/disco-vm-101@pre-updaterbd map, utile invece se vuoi usare un'immagine RBD come un normale device Linux, es. /dev/rbd0, fuori dal contesto di una VM).
Come questi due mondi si incontrano davvero: stessi nodi, calcolo e storage insieme, niente SAN da comprare a parte.
# Su ogni nodo del cluster Proxmox:
pveceph install
pveceph init --network 10.10.10.0/24 # la rete dedicata Ceph (cap. 9)
# Il primo nodo crea il monitor iniziale, poi si aggiungono gli altri
pveceph mon create
# Per ogni disco fisico da dedicare a Ceph, su ogni nodo
pveceph osd create /dev/sdb
# Crea il pool che useranno le VM
pveceph pool create vm-storage --size 3 --min_size 2Da Datacenter → Storage → Add → RBD, colleghi il pool Ceph appena creato come storage disponibile per tutti i nodi del cluster: da questo momento, ogni nodo può creare dischi VM su quello storage condiviso.
Con storage locale, migrare una VM viva tra nodi richiede copiare l'intero disco. Con Ceph, il disco è già visibile e accessibile da ogni nodo del cluster: la migrazione sposta solo lo stato di RAM/CPU della VM, ed è esattamente il motivo per cui l'HA Manager di Proxmox può riavviare una VM su un altro nodo dopo un guasto — il suo disco non è mai stato legato a un host specifico.
RBD basta per i dischi delle VM. CephFS entra in gioco quando serve una cartella condivisa POSIX tra più nodi o container.
A differenza di RBD (un blocco che appartiene tipicamente a una sola VM alla volta), CephFS è un filesystem POSIX montabile contemporaneamente da più client, come un NFS distribuito ma senza il single point of failure di un server NFS singolo. Richiede almeno un demone MDS attivo (cap. 2) per gestire i metadati (nomi file, permessi, struttura directory).
ceph fs volume create datashare
ceph fs status
# Montaggio via kernel client (piu' performante)
mount -t ceph mon1,mon2,mon3:/ /mnt/datashare -o name=admin,secret=AQ...Il terzo modo di accedere a Ceph, meno legato all'uso tipico di Proxmox ma utile per completare il quadro.
Il RADOS Gateway espone un'interfaccia compatibile con le API Amazon S3 e OpenStack Swift, permettendo ad applicazioni scritte per il cloud pubblico di usare storage a oggetti on-premise senza modifiche al codice. Tipico per backup applicativi, archiviazione a lungo termine, o come backend per strumenti che già parlano S3 nativamente.
ceph orch apply rgw mio-gateway --placement="nodo1"
radosgw-admin user create --uid=app1 --display-name="App 1"Ceph replica ogni scrittura in modo sincrono su più nodi prima di confermarla: la rete non è un dettaglio, è il fattore che decide le performance percepite.
Ceph distingue (opzionalmente, ma consigliato) la public network (client verso il cluster, es. Proxmox verso Ceph) dalla cluster network (traffico di replica tra gli OSD stessi). Separarle su interfacce fisiche diverse evita che il traffico di replica interno "rubi" banda a quello dei client in produzione.
Una scrittura con size=3 deve arrivare e essere confermata da tutte e 3 le repliche prima che il client riceva l'ack. Ogni millisecondo di latenza di rete si somma direttamente alla latenza percepita da ogni singola scrittura: per carichi random-write intensi (tipici delle VM), la latenza della rete conta spesso più della sua larghezza di banda nominale.
Il primo comando che lanci ogni volta che qualcosa sembra strano, e cosa significano davvero i suoi tre possibili stati.
ceph -s
ceph health detail
watch ceph -s # aggiornamento live durante un rebalance (cap. 11)| Stato | Significato |
|---|---|
| HEALTH_OK | Tutto normale, nessuna azione richiesta |
| HEALTH_WARN | Qualcosa richiede attenzione ma non è ancora critico (es. un OSD quasi pieno, clock non sincronizzato tra nodi) |
| HEALTH_ERR | Problema serio: dati a rischio o già inaccessibili (PG incomplete/down) |
Ceph include una dashboard web nativa (abilitata dal demone MGR) con grafici su capacità, I/O, stato degli OSD. Proxmox VE integra il proprio pannello Ceph riassuntivo direttamente nella sua interfaccia, comodo per non dover aprire due console separate.
Ceph verifica periodicamente in background l'integrità dei dati: lo scrub confronta metadati, il deep-scrub (più pesante, meno frequente) rilegge e verifica il checksum di ogni byte. Sono pianificati automaticamente in finestre di bassa attività, ma su cluster già sotto stress possono essere una causa di rallentamento visibile.
Aggiungere capacità e sostituire un disco guasto sono operazioni di routine. Farle nel modo sbagliato, con più guasti insieme, non lo è.
pveceph osd create /dev/sdc
-- oppure, Ceph nativo:
ceph-volume lvm create --data /dev/sdcceph osd out osd.7
-- attendi che il rebalance ricrei le copie mancanti --
ceph osd crush remove osd.7
ceph auth del osd.7
ceph osd rm osd.7osd_max_backfills e osd_recovery_max_active permettono di limitare quanta banda dedicare al rebalance, sacrificando velocità di recovery per non degradare troppo le performance in produzione durante l'operazione.
size=3 e failure domain a livello host (cap. 3), rimuovere OSD da due host diversi nello stesso momento può lasciare alcuni oggetti con una sola copia rimasta, o addirittura zero se il timing è sfortunato. Le manutenzioni pianificate vanno fatte un host alla volta, aspettando che il cluster torni HEALTH_OK prima di procedere al successivo.
Ceph è già di per sé un sistema ad alta affidabilità: qui i punti in cui si collega direttamente ai principi della guida dedicata.
I demoni MON (cap. 2) devono raggiungere un quorum (maggioranza) per validare ogni cambiamento alla mappa del cluster — esattamente il concetto spiegato nella guida Alta Affidabilità, cap. 5. Per questo servono sempre un numero dispari di MON (3 o 5), mai un numero pari che potrebbe finire in parità durante una partizione di rete.
Mentre la guida Alta Affidabilità parla di fencing attivo (spegnere un nodo sospetto), Ceph risolve un problema simile passivamente: distribuendo le repliche su host diversi (cap. 3), la perdita di un intero host (anche senza fencing esplicito) non può mai far perdere più di una copia di ogni oggetto, finché size e failure domain sono configurati correttamente.
Tutto quello che serve, su una pagina. Bookmark questa sezione e dimentica il resto.
ceph -s
ceph health detail
ceph osd tree
ceph dfrbd ls pool
rbd info pool/immagine
rbd resize pool/immagine --size N
rbd snap create pool/immagine@nomepveceph install
pveceph osd create /dev/sdX
pveceph pool create nome --size 3ceph osd out osd.N
ceph osd crush remove osd.N
ceph auth del osd.N
ceph osd rm osd.Nmin_size mai a 1 su pool con dati importantiHEALTH_OKceph -s prima di qualsiasi intervento, semprepg_num a mano ignorando l'autoscaler senza motivoHEALTH_WARN pensando "tanto funziona ancora"min_size mai troppo basso, e manutenzione un host alla volta aspettando HEALTH_OK. Il resto — CRUSH, erasure coding, RGW — lo approfondisci quando il cluster cresce abbastanza da farlo servire davvero, non prima.