Ceph Storage in produzione: architettura, gestione e supporto enterprise

6 lug
Tempo di lettura: 9 min

Ceph Storage in produzione: architettura, gestione e supporto enterprise

Ceph è oggi lo storage distribuito open-source più diffuso nelle infrastrutture cloud enterprise europee. Lo usano cloud provider, operatori telco, università, ospedali e banche — spesso senza che gli utenti finali lo sappiano, perché Ceph lavora sotto il cofano di OpenStack, Kubernetes e decine di altre piattaforme.

Eppure, nonostante la diffusione capillare, Ceph rimane una delle tecnologie più complesse da gestire in produzione. La differenza tra un cluster Ceph ben configurato e uno mal gestito non si misura in funzionalità — si misura in performance, disponibilità e, nei casi peggiori, in perdita di dati.

Cos'è Ceph e perché è diventato lo standard de facto

Ceph è una piattaforma di storage distribuito software-defined che unifica tre tipologie di storage su un'unica infrastruttura: storage a blocchi (RBD), storage a oggetti (compatibile S3/Swift) e storage condiviso (CephFS). Questa unificazione è uno dei suoi punti di forza principali — invece di gestire tre sistemi separati per tre esigenze diverse, Ceph le risolve tutte con un'unica piattaforma, un'unica API di gestione e un unico pool di hardware.

La scelta di Ceph come storage di riferimento per OpenStack non è casuale. Cinder, il servizio di block storage di OpenStack, si integra nativamente con Ceph RBD. Glance, il servizio di gestione delle immagini, usa Ceph come backend. Nova, il servizio di compute, può eseguire le VM direttamente su volumi Ceph con copy-on-write — riducendo i tempi di provisioning da minuti a secondi.

Lo stesso vale per Kubernetes: Rook-Ceph è oggi uno degli operatori storage più maturi per Kubernetes, e permette di gestire storage persistente per i container con la stessa affidabilità di un sistema enterprise proprietario.

Il risultato è che chi sceglie Ceph non sceglie solo uno storage — sceglie la base su cui costruire un'intera infrastruttura cloud open-source, scalabile orizzontalmente, senza vendor lock-in e con piena sovranità sui dati.

Architettura Ceph: i componenti fondamentali

Per capire come Ceph funziona in produzione è necessario conoscere i suoi componenti principali e il ruolo che ognuno svolge nel cluster.

OSD — Object Storage Daemon. È il componente che gestisce fisicamente i dati. Ogni OSD corrisponde tipicamente a un disco fisico — HDD o NVMe — e si occupa di leggere, scrivere e replicare i dati. Un cluster Ceph in produzione può avere da pochi OSD a diverse migliaia. La salute degli OSD è il primo indicatore dello stato del cluster: OSD down significa riduzione della capacità di replica e, se il numero è sufficiente, perdita di accesso ai dati.

Monitor — MON. I Monitor mantengono la mappa del cluster — la struttura CRUSH map che definisce come i dati vengono distribuiti tra gli OSD. In un cluster in produzione si usano sempre almeno tre Monitor per garantire il quorum. La perdita del quorum significa che il cluster entra in stato read-only fino al ripristino: una condizione critica per qualsiasi workload in produzione.

Manager — MGR. Il Manager raccoglie le metriche del cluster, espone le API REST e gestisce i moduli di monitoring e orchestrazione. In un cluster moderno il Manager è anche il punto di accesso alla dashboard web di Ceph e all'orchestratore Cephadm.

MDS — Metadata Server. Il Metadata Server è necessario solo quando si usa CephFS, il filesystem distribuito di Ceph. Gestisce i metadati del filesystem — directory, permessi, attributi — mentre i dati effettivi restano negli OSD.

RADOS Gateway — RGW. Il RADOS Gateway espone un'API compatibile con S3 e Swift per lo storage a oggetti. Per chi ha applicazioni che usano già l'API S3 di AWS, RGW permette di mantenere lo stesso codice puntando a un cluster Ceph on-premise — senza modifiche applicative.

In sintesi:

Componente	Ruolo	Minimo in produzione
OSD	Gestione fisica dei dati	3+ per rack fault tolerance
Monitor	Mappa del cluster e quorum	3 (sempre dispari)
Manager	Metriche, API, dashboard	2 (active + standby)
MDS	Metadati CephFS	2+ se si usa CephFS
RGW	API S3/Swift compatibile	2+ per alta disponibilità

CRUSH Map: il cuore della distribuzione dei dati

La CRUSH Map è l'algoritmo che decide dove vengono scritti i dati nel cluster. Non è un semplice round-robin — è un algoritmo deterministico che tiene conto della topologia fisica del cluster: quale OSD si trova in quale host, in quale rack, in quale sala server, in quale data center.

Configurare correttamente la CRUSH Map è uno degli aspetti più critici — e più sottovalutati — di un cluster Ceph in produzione. Una CRUSH Map mal configurata può fare sì che le repliche di un dato finiscano sugli stessi dischi fisici, vanificando la protezione dalla perdita di dati. Una CRUSH Map ottimizzata garantisce che ogni replica sia su un host diverso, su un rack diverso e, per i deployment multi-sito, su un data center diverso.

La regola di replica di default di Ceph è tre repliche — ogni dato scritto nel cluster viene replicato tre volte. Questo significa che un cluster con capacità raw di 100 TB ha una capacità utile di circa 33 TB. Per carichi di lavoro dove la capacità è più importante della ridondanza, Ceph supporta anche l'erasure coding — un meccanismo simile al RAID che permette di ottenere efficienze di storage dell'80% o superiori, a fronte di un costo computazionale maggiore nelle operazioni di scrittura.

BlueStore: il backend di storage di Ceph moderno

Fino a Ceph Luminous, il backend di storage degli OSD era FileStore — basato su un filesystem Linux standard (tipicamente XFS) con un layer di journaling separato. FileStore era affidabile ma aveva limitazioni significative di performance, specialmente con i dischi NVMe.

Da Ceph Luminous in poi, il backend di default è BlueStore — un backend completamente custom che scrive direttamente sui dispositivi a blocchi, bypassando il filesystem del sistema operativo. I vantaggi sono significativi: latenza inferiore, throughput superiore, checksum nativi per ogni dato scritto e nessun overhead del double-write del journaling.

BlueStore usa RocksDB per gestire i metadati degli OSD. In un cluster NVMe ad alte prestazioni, separare il dispositivo RocksDB dal dispositivo dati è uno degli interventi di tuning più efficaci — riduce la latenza delle operazioni di lettura e aumenta il throughput complessivo del cluster.

I casi d'uso Ceph in produzione

Ceph non è una soluzione universale ottimale per ogni caso d'uso. Capire quando Ceph eccelle e quando altri approcci sono più appropriati è fondamentale per progettare un'infrastruttura storage efficiente.

Storage per infrastrutture OpenStack. È il caso d'uso per cui Ceph è stato originariamente ottimizzato. L'integrazione nativa con Cinder, Glance e Nova, la capacità di gestire migliaia di volumi concorrenti e la scalabilità orizzontale rendono Ceph la scelta naturale per qualsiasi cloud OpenStack di dimensioni medio-grandi.

Storage persistente per Kubernetes. Con Rook-Ceph, il cluster Ceph viene gestito come un operatore Kubernetes nativo. I PersistentVolumeClaim vengono soddisfatti automaticamente da Ceph RBD, con supporto per ReadWriteOnce e, con CephFS, per ReadWriteMany. È la scelta più matura per storage persistente su Kubernetes in ambienti on-premise.

Object storage S3-compatible. Con RGW, Ceph offre un object storage S3-compatible on-premise ideale per backup, archivio dati, storage di immagini e video, dati di log e qualsiasi workload che su cloud pubblico userebbe S3. La compatibilità S3 permette di usare gli stessi client, SDK e strumenti già usati con AWS — senza modifiche.

Backup e disaster recovery. Ceph supporta la replica asincrona tra cluster geograficamente distanti — RBD mirroring per i volumi block e multi-site RGW per l'object storage. Questo permette di costruire architetture di DR dove i dati vengono replicati continuamente su un secondo sito, con RPO misurabile in secondi.

HPC e AI/ML workload. CephFS con un cluster NVMe ottimizzato può fornire throughput sequenziale nell'ordine dei GB/s — sufficiente per workload HPC e per il training di modelli AI/ML che richiedono accesso rapido a grandi dataset distribuiti su più nodi di compute.

I problemi più comuni nei cluster Ceph in produzione

Anni di esperienza su cluster Ceph in produzione ci hanno insegnato che i problemi più frequenti seguono pattern ricorrenti.

Placement Group in stato degraded o undersized. È il segnale più comune di un cluster che sta perdendo ridondanza. Può essere causato da OSD down, da una CRUSH Map che non riesce a soddisfare le regole di replica, o da un cluster in fase di rebalancing dopo l'aggiunta o la rimozione di nodi. Un cluster con PG degraded non ha perso dati — ma ha ridotto la protezione dalla perdita di dati fino al ripristino.

Performance anomale su workload random I/O. Ceph è ottimizzato per workload sequenziali. Workload con molte operazioni random di piccole dimensioni — tipici di database OLTP — possono saturare la capacità di IOPS del cluster prima di saturare il throughput. Il tuning del numero di PG, la separazione dei journal NVMe dai dati HDD e la configurazione del cache tiering sono gli interventi più efficaci in questi scenari.

OSD flapping. Situazione in cui uno o più OSD entrano e escono ciclicamente dallo stato up/down. Le cause più comuni sono problemi di rete tra i nodi del cluster, dischi con settori difettosi che causano timeout nelle operazioni di I/O, o memoria insufficiente che causa OOM kill del processo OSD. Il flapping degli OSD genera un volume elevato di operazioni di recovery che possono saturare la banda di rete del cluster.

Rebalancing eccessivo dopo modifiche al cluster. Ogni volta che si aggiunge o rimuove un OSD, Ceph ricalcola la distribuzione dei dati e sposta i PG per bilanciare il cluster. In un cluster grande, questo può generare centinaia di GB di traffico di rete. Configurare correttamente il parametro target_max_bytes e usare lo strumento osd reweight invece di aggiungere OSD grandi in un colpo solo è fondamentale per mantenere le performance durante le fasi di espansione.

Come Epic Edge supporta i cluster Ceph in produzione

Il team di Epic Edge lavora su cluster Ceph in produzione per cloud provider, operatori telco e infrastrutture enterprise da anni. Il supporto che forniamo copre l'intero ciclo di vita del cluster — dalla progettazione iniziale alla gestione quotidiana, dagli upgrade alle espansioni.

Assessment e health check. Il punto di partenza per qualsiasi intervento è un'analisi completa dello stato del cluster: versione Ceph, configurazione degli OSD, stato dei Monitor, CRUSH Map, distribuzione dei PG, metriche di performance e log degli ultimi incident. In 24-48 ore il cliente riceve un report dettagliato con le criticità identificate e le azioni correttive raccomandate, con prioritizzazione in base all'impatto potenziale.

Troubleshooting e incident response. Per i cluster in crisi — OSD down, PG bloccati in stato inconsistent, perdita del quorum dei Monitor — il team Epic Edge interviene con SLA garantito. Il tempo di risposta per incident critici P1 è di 30 minuti. L'obiettivo di ogni intervento è il ripristino del cluster con il minimo impatto sui workload in produzione.

Ottimizzazione delle performance. Il tuning di un cluster Ceph è un processo iterativo che richiede comprensione profonda del workload specifico. Ottimizziamo la configurazione di BlueStore, il dimensionamento dei PG, la separazione dei dispositivi NVMe per i metadati RocksDB, le policy di replica e l'erasure coding in base al profilo di utilizzo reale del cluster.

Upgrade tra versioni major. Gli upgrade Ceph tra versioni major — da Pacific a Quincy, da Quincy a Reef — richiedono una pianificazione attenta e una procedura rolling testata. Epic Edge pianifica ed esegue gli upgrade in finestre di manutenzione concordate, con test sistematici ad ogni step e procedure di rollback pronte in caso di necessità.

Espansione e scaling. L'aggiunta di nuovi OSD, host e rack a un cluster esistente richiede la modifica della CRUSH Map, il rebalancing dei dati e la verifica delle performance post-espansione. Epic Edge gestisce l'intero processo garantendo che il cluster rimanga operativo durante la fase di espansione.

Monitoraggio proattivo 24/7. Il NOC Epic Edge monitora lo stato dei cluster Ceph dei clienti in gestione con alerting proattivo su anomalie, soglie di capacità, OSD in stato di warning e degradazione delle performance. L'obiettivo è intervenire prima che i problemi diventino incident critici.

Ceph e la sovranità dei dati in Europa

Un aspetto sempre più rilevante per le organizzazioni europee è la localizzazione dei dati. Ceph, essendo una piattaforma software-defined open-source, può essere deployato su qualsiasi hardware, in qualsiasi data center, sotto qualsiasi giurisdizione.

Questo lo rende la scelta naturale per chi deve garantire che i propri dati rimangano in Europa — senza dipendere da un provider cloud americano soggetto al Cloud Act USA. Con Ceph deployato su infrastruttura del cliente o in data center europei, la sovranità dei dati è strutturale, non dichiarata contrattualmente da un vendor che potrebbe essere costretto a violarla.

La conformità GDPR e NIS2 diventa più semplice da dimostrare quando l'intera catena di custodia dei dati — dall'hardware al software di storage — è sotto il controllo diretto dell'organizzazione o di un provider europeo certificato.

Conclusione: Ceph è maturo, ma richiede competenza

Ceph è una piattaforma straordinariamente capace. È anche una piattaforma che richiede competenza specifica per essere gestita correttamente in produzione — non perché sia difettosa, ma perché la complessità di un sistema distribuito su larga scala non si elimina, si gestisce.

La differenza tra un cluster Ceph che funziona e uno che performa è nella qualità della configurazione iniziale, nella comprensione del workload specifico e nella capacità di intervenire rapidamente quando qualcosa non va come previsto.

Per le organizzazioni che non hanno questa competenza internamente — o che vogliono affiancarla a un team specializzato — il supporto enterprise di un partner con esperienza reale su cluster Ceph in produzione non è un costo aggiuntivo. È un investimento nella continuità operativa.