News

OVHcloud spiega Exten, il motore NVMe che sostituisce Ceph sul Public Cloud

OVHcloud dettaglia l'architettura di Exten, lo storage a blocchi NVMe-oF sviluppato in casa che da oltre un anno alimenta i volumi Public Cloud al posto di Ceph.

Redazione UptimeMag · 6 agosto 2026 · 2 minuti di lettura

OVHcloud spiega Exten, il motore NVMe che sostituisce Ceph sul Public Cloud

OVHcloud ha pubblicato sul proprio blog tecnico i dettagli di Exten, il motore di storage a blocchi NVMe che da più di un anno alimenta i volumi del Public Cloud al posto di Ceph. Per chi gestisce VM e database su questa piattaforma, non cambia nulla lato attacco del volume, ma cambia tutto quello che c'è sotto: un motore scritto in casa, pensato per ridurre i costi a parità di prestazioni.

Perché un motore proprietario

Per offrire più prestazioni a un costo minore, OVHcloud ha acquisito Exten, ed è ora in grado di costruire un proprio motore di storage a blocchi NVMe scritto in C++ e Go. L'acquisizione tecnologica risale al 2020: OVHcloud ha acquisito la tecnologia di EXTEN Technologies, società statunitense specializzata in NVMe over Fabrics, con sede ad Austin, Texas.

Come è fatto un cluster

Un tipico cluster Exten è composto da sei server, posizionati abbastanza vicini da avere bassa latenza tra loro, ma non troppo per limitare il rischio che più server si guastino insieme; ogni server ha decine di drive NVMe per i dati degli utenti. Il protocollo usato è NVMe over Fabric sia per esporre i volumi sia per far comunicare gli host tra loro: stessi comandi dell'NVMe locale, ma su rete TCP o RDMA. Il kernel Linux lo supporta nativamente: basta un comando nvme connect con i parametri giusti e il volume appare come un drive locale qualsiasi; per il cliente Public Cloud resta trasparente, esattamente come con Ceph.

L'architettura software separa le responsabilità: Exten è diviso in un data plane scritto in C++ e un control plane scritto in Go, che comunicano via gRPC.

Affidabilità: Raft e Reed-Solomon

Sul control plane, il consenso tra i nodi passa dall'algoritmo Raft: un cluster da sei host può perdere due nodi e continuare a funzionare, perché serve solo la maggioranza per evitare lo split-brain.

Per i dati utente, che passerebbero troppo lentamente attraverso Raft, OVHcloud usa un codice Reed-Solomon in configurazione 4+2: i dati vengono divisi in quattro parti uguali, a cui si aggiungono due parti di parità calcolate; bastano quattro parti qualsiasi delle sei per ricostruire l'originale. Questo dà un rapporto di 1,5 tra spazio occupato e dati ricevuti, contro il fattore 3 che servirebbe con una mirror a tre copie per tollerare la stessa perdita di due drive.

Prossimi passi

Exten alimenta oggi le stesse offerte che prima poggiavano su Ceph, senza differenze visibili per il cliente. OVHcloud dichiara di star valutando il passaggio da TCP a RDMA per il trasporto, puntando a volumi con prestazioni più elevate.

Testo redatto con il supporto dell'intelligenza artificiale e verificato dalla redazione (AI Act, art. 50).