.png)
Affidabile e perfettamente integrato in OpenStack, Ceph è la nostra soluzione di block storage da anni. Per offrire maggiori prestazioni a un costo inferiore, abbiamo acquisito Exten: ora siamo in grado di costruire la nostra soluzione Block Storage NVMe in C++ e Go. I nostri obiettivi sono:
- Utilizzare dischi NVMe per offrire volumi ad alte prestazioni
- Utilizzare algoritmi di codifica intelligenti per ridurre le esigenze di spazio sui dischi (codice Reed-Solomon, compressione)
- Mantenere i cluster piccoli e facili da gestire
Exten è in produzione da oltre un anno. In questo blog ti spieghiamo come funziona e come la sua architettura evolverà in futuro.
Clicca sul link in fondo alla pagina per darci il tuo feedback e contribuire al futuro di Exten.
Anatomia di un cluster
Un cluster Exten è composto da sei server. Queste macchine sono vicine le une alle altre, per far sì che la latenza tra di loro sia bassa, ma non troppo: in questo modo, è meno probabile che più server abbiano un guasto contemporaneamente. Ogni server dispone di decine di dischi NVMe per salvare i dati degli utenti.
Exten è basato sul protocollo NVMe. Utilizza dischi NVMe e il protocollo NVMe over Fabric per esporre i volumi dell’utente e permettere la comunicazione tra gli host. I volumi sono unità virtuali che i clienti possono collegare alle proprie VM. Questo protocollo utilizza gli stessi comandi dei dischi NVMe, ma tramite un collegamento di rete (TCP o RDMA), ed è progettato per offrire alte prestazioni e bassa latenza.
Un vantaggio di NVMe over Fabric è che il kernel Linux lo supporta nativamente. Collegare un volume Exten a un host Linux è semplice come eseguire il comando nvme connect con i parametri corretti: il volume viene mostrato come qualsiasi altro disco NVMe locale. L’utente Public Cloud non vede nulla di tutto ciò: il volume è semplicemente collegato all’istanza, esattamente come con Ceph.
Exten è diviso in un piano dati scritto in C++ e un piano di controllo scritto in Go. Entrambi comunicano tramite gRPC. Il piano dati riceve le operazioni di I/O tramite NVMe over Fabric e le instrada verso i dischi NVMe. Il piano di controllo fornisce un'API per creare e cancellare i volumi e gestire il cluster.
Come proteggere i dati
La protezione dei dati dei clienti è la responsabilità principale di un cluster Exten e OVHcloud la gestisce su più livelli.
A livello del piano di controllo, utilizziamo il noto algoritmo di consenso Raft per garantire l'integrità del cluster in modo tollerante ai guasti. Questo protocollo elegge un leader e registra qualsiasi nuova informazione (un nuovo volume, un disco abilitato) in un log replicato su ogni host. In caso di malfunzionamento di un host, gli altri continuano a funzionare. L'unico limite è che la maggioranza degli host deve rimanere attiva per evitare problemi di “split-brain”: un cluster a sei nodi può perdere due host e continuare a funzionare.
I dati utente e le operazioni di I/O effettuate sui volumi non passano attraverso Raft: sarebbe un processo troppo lento. Al suo posto, utilizziamo un altro algoritmo conosciuto: un codice Reed-Solomon.
Questo codice di correzione degli errori è concettualmente semplice. Consideriamo RS 4+2: dividiamo i dati in quattro parti uguali, quindi calcoliamo due nuove parti della stessa dimensione. Se riesci a leggere quattro di quelle sei parti, puoi recuperare i dati originali: il codice ti consente di calcolare le due parti mancanti. Si ottiene quindi un rapporto di 1,5 (dati salvati/dati ricevuti), che ci permette di perdere due dischi senza perdere dati. È un modo molto efficiente di aggiungere ridondanza. L'alternativa più semplice, solitamente chiamata mirroring, che consiste nel copiare tutti i dati più volte su dischi diversi, avrebbe bisogno di tre copie per sopravvivere alla perdita di due dischi. Con Reed-Solomon, salviamo metà dei dati con lo stesso livello di ridondanza.
I dischi guasti possono essere individuati in due modi: una lettura non va a buon fine, oppure restituisce dati corrotti, che vengono rilevati grazie a un checksum che aggiungiamo a ogni settore. In caso di malfunzionamento di un disco, un processo automatico ricalcola la parte mancante e la salva su un disco sano, riducendo il rischio di perdita di dati.
Eseguire operazioni di I/O rapidamente
Con una CPU e una RAM che lavorano più velocemente, lo storage deve fare altrettanto. L'obiettivo di Exten è sfruttare al massimo l'hardware su cui lavora e fornire I/O ad alte prestazioni ai clienti. Scegliere il protocollo NVMe over Fabric è un primo passo per ottenere I/O con il minor overhead possibile, anche se tutto lo stack software è progettato per offrire prestazioni elevate.
Il modello di elaborazione è incentrato sui dati. A livello della Network Interface Card (NIC), riceviamo e inviamo dati tramite una lista di buffer di dimensione fissa salvati nella RAM. Una CPU elabora ogni buffer con due obiettivi: evitare le copie di dati e i cambi di contesto.
Per evitare le copie di dati, il codice manipola buffer pre-allocati tramite puntatori dalla NIC al disco, e i dati vengono modificati solo quando è inevitabile (compressione, codice Reed-Solomon, ecc.). Per evitare i cambi di contesto, gestiamo l'I/O tramite metodi completamente asincroni che lavorano su piccoli pezzi di dati. Una CPU esegue quanta elaborazione possibile su un buffer prima di passare al successivo, ma deve crearsi un equilibrio: il buffer successivo non può essere ritardato troppo a lungo e l'elaborazione deve rimanere equa. Abbiamo costruito un intero framework C++ adatto a queste esigenze, in modo che il codice sia chiaro e mantenibile.
Oltre al codice, diversi fattori contribuiscono a migliorare le prestazioni:
- la scelta dell'algoritmo di compressione (a volte la scelta migliore è non comprimere, ad esempio sul traffico crittografato)
- la scelta del protocollo di rete: RDMA è più veloce di TCP, ma comporta più vincoli di deploy
- il modo in cui assegniamo i core CPU ai volumi
Nelle nostre offerte Public Cloud, applichiamo anche regole QoS per garantire una distribuzione equa tra i volumi.
Il futuro di Exten
Exten è attualmente in produzione e fornisce volumi ai clienti Public Cloud. È trasparente per gli utenti e supporta le stesse offerte di Ceph, ma è uno stack software che controlliamo al 100%, costruito su NVMe per offrire prestazioni elevate.
Miglioriamo questa soluzione costantemente, con l'obiettivo di offrire ai clienti volumi con prestazioni ottimizzate, maggiore flessibilità e affidabilità. Ad esempio, stiamo testando l'uso di RDMA per migliorare le prestazioni (attualmente utilizziamo TCP).
Il primo passo nel percorso di Exten è stato quello di fornire un'offerta affidabile che sostituisse Ceph. Ora che abbiamo il pieno controllo dello stack, siamo pronti ad aggiungere nuove funzionalità e ad adattare la soluzione alle esigenze dei clienti.
Hai in mente casi d'uso per Block Storage che dovremmo conoscere, o funzionalità che secondo te andrebbero aggiunte? Parlacene su Discord o nella cloud mailing-list: la tua opinione contribuirà al futuro di Exten.