OpenStack senza Ceph non è un cloud vero: perché lo storage distribuito è il fondamento dell'IaaS enterprise

OpenStack senza Ceph non è un cloud vero: perché lo storage distribuito è il fondamento dell'IaaS enterprise

Chi si avvicina a OpenStack per la prima volta tende a concentrarsi sul compute — Nova, le VM, il networking con Neutron. Lo storage viene dopo, trattato come un dettaglio implementativo da risolvere quando il resto funziona.

È un errore che si paga caro in produzione.

Lo storage non è un componente accessorio di un'infrastruttura cloud enterprise. È il fondamento su cui tutto il resto poggia — le VM, le immagini, i volumi persistenti, l'object storage. E in un'infrastruttura OpenStack seria, quel fondamento si chiama Ceph.

Perché lo storage è il vero discrimine tra un lab e un cloud in produzione

Un cluster OpenStack funziona anche senza Ceph. Si può configurare con storage locale sugli hypervisor, con un NFS condiviso, con un array SAN proprietario. In un ambiente di test o di sviluppo, queste soluzioni sono perfettamente adeguate.

In produzione, con carichi di lavoro reali, il discorso cambia radicalmente.

Lo storage locale sugli hypervisor significa che le VM sono legate fisicamente al nodo su cui girano — la live migration diventa impossibile o molto limitata, il failover automatico non funziona come dovrebbe, e ogni guasto hardware porta con sé il rischio di perdita di dati.

NFS condiviso introduce un single point of failure e un collo di bottiglia nelle performance che si manifesta sotto carico. Funziona fino a quando il numero di VM e IOPS rimane contenuto — poi collassa.

Gli array SAN proprietari risolvono alcuni di questi problemi ma ne introducono di nuovi: costi elevati, vendor lock-in, scalabilità rigida e una dipendenza hardware che mal si concilia con la filosofia open-source di OpenStack.

Ceph è nato per risolvere questi problemi strutturalmente, non con patch o workaround.

L'integrazione nativa tra OpenStack e Ceph

La ragione per cui Ceph è diventato lo storage di riferimento per OpenStack non è solo tecnica — è architettuale. I due sistemi sono stati progettati per lavorare insieme, e l'integrazione tra i componenti OpenStack e Ceph è nativa, profonda e ottimizzata.

Nova e Ceph RBD — il provisioning delle VM

Quando Nova, il servizio di compute di OpenStack, viene configurato con Ceph come backend, le VM non vengono più create copiando un'immagine sul disco locale dell'hypervisor. Vengono avviate direttamente su volumi RBD nel cluster Ceph, con copy-on-write.

Il risultato pratico è immediato: il tempo di provisioning di una nuova VM passa da minuti — il tempo necessario per copiare un'immagine da decine di GB — a secondi. Il disco dell'immagine base rimane nel cluster Ceph come snapshot read-only, e ogni nuova VM riceve semplicemente un layer copy-on-write sopra di essa. Nessuna copia, nessun trasferimento di dati, nessuna attesa.

Questo cambia radicalmente la user experience del cloud — e l'efficienza operativa per chi lo gestisce.

Cinder e Ceph RBD — i volumi persistenti

Cinder, il servizio di block storage di OpenStack, si integra nativamente con Ceph RBD per la gestione dei volumi persistenti. Ogni volume Cinder è un RBD image nel cluster Ceph — replicato su tre nodi per default, indipendente dall'hypervisor su cui gira la VM che lo usa.

Questo disaccoppiamento è fondamentale. Una VM con un volume Cinder può essere migrata live da un hypervisor all'altro senza alcuna interruzione del servizio — il volume rimane nel cluster Ceph e la nuova posizione della VM lo raggiunge attraverso la rete. Il failover automatico in caso di guasto di un hypervisor diventa possibile e trasparente per l'utente finale.

Gli snapshot dei volumi Cinder su backend Ceph sono operazioni quasi istantanee — non richiedono la copia fisica dei dati ma solo la creazione di un snapshot RBD, che è un'operazione a livello di metadati. Questo rende possibile policy di snapshot frequenti senza impatto sulle performance.

Glance e Ceph — la gestione delle immagini

Glance, il servizio di gestione delle immagini di OpenStack, usa Ceph come backend per archiviare le immagini delle VM. Questo porta due vantaggi concreti.

Il primo è la condivisione efficiente delle immagini — un'immagine Ubuntu o CentOS caricata una volta nel cluster Ceph è disponibile su tutti gli hypervisor senza doverla copiare localmente su ciascuno. In un cluster con decine o centinaia di nodi compute, questo riduce enormemente il traffico di rete durante il provisioning.

Il secondo è l'integrazione con Nova per il copy-on-write descritto sopra — quando Nova avvia una VM da un'immagine Glance su backend Ceph, l'immagine viene semplicemente clonata come RBD snapshot, senza alcuna copia fisica dei dati.

RGW — l'object storage S3-compatible

Il RADOS Gateway di Ceph espone un'API compatibile con S3 e Swift direttamente dal cluster Ceph esistente. Per un cloud OpenStack enterprise questo significa avere object storage S3-compatible nativo, senza dover gestire un sistema separato.

Per i workload che usano già l'API S3 — backup, archiviazione, storage di log, dati di applicazioni — RGW permette di continuare a usare gli stessi client e SDK senza modifiche, puntando a un cluster on-premise invece di AWS S3. La sovranità dei dati è strutturale, non dichiarata contrattualmente.

Le performance: dove Ceph cambia le regole del gioco

Un malinteso comune su Ceph è che sia uno storage "abbastanza buono" per i carichi di lavoro cloud, ma non all'altezza delle performance degli array SAN enterprise per i workload più esigenti.

In un cluster correttamente dimensionato e ottimizzato, questo non è vero.

BlueStore e NVMe

Dalla versione Luminous, Ceph usa BlueStore come backend di default per gli OSD — un backend custom che scrive direttamente sui dispositivi a blocchi senza l'overhead di un filesystem intermedio. Con dischi NVMe, un cluster Ceph con BlueStore ottimizzato raggiunge latenze nell'ordine delle centinaia di microsecondi e throughput nell'ordine dei GB/s per singolo OSD.

La separazione del dispositivo RocksDB — che gestisce i metadati degli OSD — su un NVMe dedicato rispetto ai dati è uno degli interventi di tuning più efficaci. In un cluster con HDD per i dati e NVMe per i metadati, le latenze di lettura si riducono drasticamente perché le operazioni di lookup dei metadati non competono con le operazioni di I/O sui dati.

Scalabilità orizzontale senza colli di bottiglia

La differenza fondamentale tra Ceph e un array SAN tradizionale è il modello di scalabilità. Un array SAN scala verticalmente — si aggiunge capacità e performance allo stesso sistema fisico, fino ai limiti hardware dell'array. Quando si raggiunge il limite, si compra un array più grande.

Ceph scala orizzontalmente — si aggiungono nodi OSD, e la capacità e le performance crescono linearmente con il numero di nodi. Non c'è un limite architetturale — i cluster Ceph più grandi al mondo gestiscono exabyte di dati su migliaia di OSD. E l'aggiunta di nuovi nodi avviene a cluster live, senza interruzione del servizio.

Quando Ceph fa la differenza in produzione

Ci sono scenari specifici in cui la scelta tra Ceph e alternative più semplici determina il successo o il fallimento dell'infrastruttura.

Alta disponibilità e failover automatico

In un cluster OpenStack con Ceph, il failover di un hypervisor è gestibile in modo completamente automatico. Quando un nodo compute va offline, le VM che vi giravano possono essere riavviate automaticamente su altri hypervisor — i loro volumi Ceph sono già disponibili nel cluster, non richiedono alcuna operazione di recovery dello storage.

In un cluster con storage locale, lo stesso scenario richiede prima di recuperare i dati dal nodo guasto — ammesso che sia possibile — prima di poter riavviare le VM altrove. I tempi di recovery si misurano in ore invece di minuti.

Live migration trasparente

La live migration — spostare una VM da un hypervisor all'altro senza interruzione del servizio — richiede che lo storage della VM sia accessibile da tutti i nodi compute. Con Ceph, questo è strutturalmente garantito: tutti i nodi compute vedono lo stesso cluster Ceph attraverso la rete, e la migrazione live è un'operazione trasparente per la VM e per l'utente finale.

Multi-tenancy e isolamento

In un cloud multi-tenant — dove diversi clienti o business unit condividono la stessa infrastruttura fisica — lo storage deve garantire l'isolamento completo tra i tenant. Con Ceph, ogni tenant ha i propri pool, con le proprie quote di capacità, le proprie policy di replica e i propri snapshot. L'isolamento è garantito a livello di cluster, non solo a livello applicativo.

Perché non tutti i deployment Ceph funzionano bene

Ceph è potente, ma la distanza tra un cluster Ceph che funziona e uno che performa è nella qualità della configurazione e nella comprensione del workload.

I problemi più comuni che vediamo sui cluster in produzione sono quasi sempre gli stessi: CRUSH Map configurata senza considerare la topologia fisica dell'hardware, numero di Placement Group dimensionato male rispetto alla capacità del cluster, mancanza di separazione tra rete pubblica e rete cluster, OSD HDD e NVMe mescolati nello stesso pool senza cache tiering, BlueStore non ottimizzato per il tipo di workload.

Ognuno di questi errori ha un impatto misurabile sulle performance e sulla stabilità — un cluster Ceph mal configurato può degradare le performance del 50-70% rispetto al potenziale reale, e può manifestare comportamenti anomali sotto carico che non si vedono nei test iniziali.

La corretta configurazione di un cluster Ceph enterprise non è un'operazione plug-and-play. Richiede comprensione profonda dell'architettura, del workload specifico e delle interazioni tra i componenti.

Conclusione

OpenStack è una piattaforma IaaS straordinariamente capace. Ma la sua capacità in produzione — alta disponibilità, live migration, provisioning veloce, scalabilità orizzontale, multi-tenancy — si esprime pienamente solo quando lo storage è all'altezza.

Ceph non è un'opzione tra tante per lo storage di un cluster OpenStack enterprise. È il fondamento su cui quella capacità si costruisce.

Chi sceglie OpenStack senza pianificare correttamente lo storage Ceph sta costruendo su sabbia — e lo scoprirà quando il carico di produzione inizierà a fare pressione sui punti deboli dell'architettura.

Hai un cluster OpenStack o stai pianificando un'infrastruttura IaaS enterprise?

Epic Edge progetta e gestisce infrastrutture OpenStack con Ceph su hardware del cliente, con SLA 99,99% e supporto NOC/SOC 24/7.

→ Richiedi un assessment