Questo articolo è stato scritto per aiutarti a scegliere la soluzione più adatta e comprendere le differenze tra SDS come Gluster, Ceph e Vstorage (Virtuozzo).
Nel testo vengono utilizzati collegamenti a articoli che approfondiscono ulteriormente varie problematiche, quindi le descrizioni saranno il più concise possibile, con l'uso di punti chiave senza fronzoli e informazioni introduttive che potrai recuperare per conto tuo su Internet.
In realtà, ovviamente, gli argomenti trattati richiedono un certo tono nel testo, ma nel mondo moderno sempre più persone non amano leggere molto))), quindi puoi dare una lettura veloce e prendere una decisione, e se c'è qualcosa di poco chiaro, puoi seguire i link o cercare parole sconosciute))), e questo articolo funge da involucro trasparente per questi argomenti profondi, mostrando il contenuto – i punti chiave principali di ciascuna soluzione.
Gluster
Iniziamo con Gluster, che è ampiamente utilizzato dai produttori di piattaforme iperconvergenti con SDS basato su open source per ambienti virtuali e può essere trovato sul sito di RedHat nella sezione storage, dove viene offerta la possibilità di scegliere tra due opzioni SDS: Gluster o Ceph.
Gluster è composto da un insieme di traduttori, ovvero servizi che gestiscono tutte le operazioni di distribuzione dei file, ecc. Il Brick è il servizio che gestisce un singolo disco, mentre il Volume è un pool che unisce questi brick. Successivamente, ci sono i servizi di distribuzione dei file tramite la funzione DHT (distributed hash table). Non tratteremo il servizio di Sharding nella descrizione poiché nei collegamenti riportati di seguito verranno illustrati i problemi associati ad esso.
Quando viene scritto un file, esso viene interamente salvato in un brick e una copia viene scritta parallelamente in un brick su un secondo server. Successivamente, il secondo file verrà registrato in un'altra coppia di brick (o più) su server diversi.
Se i file sono di dimensioni simili e il volume consta di un'unica coppia, tutto funziona a meraviglia. Tuttavia, in altre condizioni, si presentano i seguenti problemi:
- lo spazio nei gruppi viene utilizzato in modo diseguale, dipende dalle dimensioni dei file; se un gruppo non ha spazio sufficiente per registrare un file, si verificherà un errore: il file non verrà scritto e non verrà ridistribuito in un altro gruppo;
- quando si scrive un file, le operazioni di I/O avvengono solo su un gruppo, mentre gli altri rimangono inattivi;
- non è possibile ottenere IO dell'intero volume durante la registrazione di un singolo file;
- e l'intera concezione appare meno performante a causa della mancanza di distribuzione dei dati su blocchi, dove è più semplice effettuare il bilanciamento e risolvere il problema della distribuzione uniforme, piuttosto che come avviene ora, dove il file viene inserito in un singolo brick.
Dalla descrizione ufficiale si comprende anche che gluster funziona come uno storage di file sopra un classico RAID hardware. Ci sono stati tentativi di sviluppare la suddivisione (Sharding) di file in blocchi, ma tutte queste aggiunte portano a una perdita di prestazioni rispetto all'approccio architetturale esistente, oltre all'uso di componenti open source con limitazioni nelle prestazioni come Fuse. Non ci sono servizi di metadati, il che limita le capacità di prestazione e di resilienza dello storage nella distribuzione dei file su blocchi. Prestazioni migliori possono essere osservate con la configurazione 'Distributed Replicated', e il numero di nodi deve essere almeno 6 per organizzare una replica affidabile di 3 con una distribuzione del carico ottimale.
Queste conclusioni sono anche correlate alla descrizione dell'esperienza d'uso e al confronto con , oltre a una descrizione dell'esperienza nell'arrivare a comprendere questa configurazione più performante e affidabile
L'immagine mostra la distribuzione del carico durante la scrittura di due file, dove le copie del primo file sono distribuite su tre dei primi server, che sono raggruppati nel volume 0, e tre copie del secondo file vanno nel secondo gruppo volume1 di tre server. Ogni server ha un disco.
La conclusione generale è che si può utilizzare Gluster, ma con la consapevolezza che ci saranno limitazioni nelle prestazioni e nella resilienza ai guasti, che creano difficoltà in determinate condizioni di una soluzione iperconvergente, dove le risorse sono necessarie anche per i carichi di lavoro di calcolo degli ambienti virtuali.
Ci sono anche alcune metriche di prestazione di Gluster che possono essere raggiunte in determinate condizioni, limitandosi a
Ceph
Ora esaminiamo Ceph attraverso le descrizioni architettoniche che sono riuscito a C'è anche un confronto tra , dove è possibile capire subito che è preferibile distribuire Ceph su server dedicati, poiché i suoi servizi necessitano di tutte le risorse hardware sotto carico.
Architettura è più complesso rispetto a Gluster e include servizi come i servizi di metadati, ma l'intero stack di componenti è piuttosto complicato e non molto flessibile per l'uso in soluzioni di virtualizzazione. I dati sono gestiti in blocchi, il che appare più performante, ma ci sono perdite e latenza nella gerarchia di tutti i servizi (componenti) sotto determinate condizioni di carico e di emergenza, come indicato nel seguente
Dalla descrizione dell'architettura, il cuore è rappresentato da CRUSH, che determina il luogo per la collocazione dei dati. Successivamente, si trova PG, che è l'astrazione più complessa (gruppo logico) da comprendere. PG è necessario affinché CRUSH sia più efficiente. Lo scopo principale di PG è raggruppare gli oggetti per ridurre il consumo di risorse, aumentare le prestazioni e la scalabilità. L'indirizzamento diretto degli oggetti, uno per uno, senza raggrupparli in PG, sarebbe molto dispendioso. OSD è il servizio per ciascun singolo disco.
Un cluster può avere uno o più pool di dati con scopi diversi e impostazioni distinte. I pool sono suddivisi in gruppi di posizionamento. Nei gruppi di posizionamento sono memorizzati gli oggetti a cui accedono i clienti. A questo livello logico termina il processo, e inizia quello fisico, poiché a ciascun gruppo di posizionamento è associato un disco principale e diversi dischi replica (il numero esatto dipende dal fattore di replicazione del pool). In altre parole, a livello logico, un oggetto è memorizzato in un gruppo di posizionamento specifico, mentre a livello fisico esso si trova su dischi ad esso assegnati. Questi dischi possono trovarsi fisicamente su nodi diversi o addirittura in centri dati differenti.
In questo schema, i gruppi di placement appaiono come un livello necessario per la flessibilità dell'intera soluzione, ma allo stesso tempo come un anello superfluo nella catena, suscitando involontariamente preoccupazioni riguardo alla perdita di prestazioni. Ad esempio, quando la sistema registra dati, è necessario suddividerli in questi gruppi e poi, a livello fisico, scriverli sul disco principale e sui dischi per le repliche. Quindi, la funzione hash opera durante la ricerca e l'inserimento di oggetti, ma ha un effetto collaterale: ci sono spese molto elevate e limitazioni nella ristrutturazione dell'hash (ad esempio, quando si aggiunge o si rimuove un disco). Un altro problema dell'hash è la posizione dei dati, che è rigidamente fissata e non può essere modificata. Ciò significa che se un disco subisce un carico elevato, il sistema non ha la possibilità di non scriverci (selezionando un altro disco); la funzione hash obbliga a posizionare i dati secondo regole, indipendentemente dalle difficoltà del disco. Pertanto, Ceph consuma molta memoria nella ristrutturazione dei PG in caso di self-healing o ampliamento dello storage. La conclusione è che Ceph funziona bene (anche se lentamente), ma solo in assenza di scalabilità, situazioni di emergenza e aggiornamenti.
Ci sono certamente opzioni per migliorare le prestazioni attraverso la cache e il tiering della cache, ma è necessario avere hardware adeguato e ci saranno comunque perdite. Tuttavia, in generale, Ceph appare più allettante rispetto a Gluster per le applicazioni produttive. Inoltre, quando si utilizzano questi prodotti, è fondamentale considerare un fattore di grande importanza: un elevato livello di competenze, esperienza e professionalità con un forte focus su Linux, poiché è cruciale installare, configurare e mantenere tutto correttamente, il che impone ulteriore responsabilità e carico all'amministratore.
Vstorage
Appare ancora più interessante l'architettura di , che può essere utilizzata insieme all'iper-vvisor sugli stessi nodi, sullo stesso , ma è molto importante configurare tutto correttamente per ottenere buone prestazioni. Cioè, l'installazione di un tale prodotto 'out of the box' su una qualsiasi configurazione senza considerare le raccomandazioni relative all'architettura sarà molto facile, ma non produttiva.
Cosa può coesistere per l'archiviazione accanto ai servizi del hypervisor kvm-qemu? Si tratta di alcune funzionalità dove è stata trovata una compatta gerarchia ottimale di componenti: il servizio client montato tramite FUSE (modificato, non open source), il servizio metadati MDS (Metadata service), il servizio di chunk di dati Chunk service, che a livello fisico è equivalente a un disco e questo è tutto. In termini di velocità, è ovviamente ottimale utilizzare uno schema di alta disponibilità in due repliche, ma se si impiega caching e log su dischi SSD, la codifica robusta contro i guasti (erase coding o raid6) può essere notevolmente accelerata su uno schema ibrido o addirittura meglio su all flash. Con l'EC (erase coding) c'è un certo svantaggio: quando un blocco di dati viene modificato, è necessario ricalcolare le somme di parità. Per aggirare le perdite concernenti a questa operazione, Ceph scrive in EC con un ritardo, e problemi di prestazioni possono verificarsi in presenza di una richiesta specifica, quando ad esempio è necessario leggere tutti i blocchi. Nel caso di Virtuozzo Storage, la scrittura dei blocchi modificati avviene utilizzando l'approccio del 'log-structured file system', il che minimizza il costo per il calcolo delle parità. Per stimare approssimativamente le opzioni per velocizzare il lavoro con e senza EC, ci sono – i numeri possono essere approssimativi a seconda del coefficiente di precisione del produttore dell'hardware, ma il risultato dei calcoli aiuta a pianificare bene la configurazione.
Uno schema semplice dei componenti di archiviazione non significa che questi componenti non consumino ma se si calcolano tutte le spese in anticipo, si può contare su un funzionamento armonioso accanto all'iper-vistore.
Esiste uno schema di confronto del consumo delle risorse hardware da parte dei servizi Ceph e Virtuozzo storage.
Se in precedenza era possibile confrontare Gluster e Ceph attraverso articoli obsoleti utilizzando le righe più importanti, con Virtuozzo è più difficile. Gli articoli su questo prodotto non sono tanti e le informazioni possono essere tratte solo dalla documentazione su o in russo se si considera Vstorage come archiviazione utilizzata in alcune soluzioni iperconvergenti in aziende come e Acronis.
Cercherò di aiutarti con la descrizione di questa architettura, quindi il testo sarà un po' più lungo, ma per comprendere la documentazione è necessario molto tempo. La documentazione esistente può essere utilizzata solo come riferimento tramite la consultazione del sommario o la ricerca per parole chiave.
Esaminiamo il processo di scrittura in una configurazione ibrida dell'hardware con i componenti descritti sopra: la scrittura inizia sul nodo da cui è stata avviata dal cliente (il servizio di montaggio FUSE), ma il componente del servizio master dei metadati (MDS) indirizzerà il cliente direttamente al servizio del chunk richiesto (il servizio di archiviazione dei blocchi CS), quindi l'MDS non partecipa al processo di scrittura, ma semplicemente indirizza al servizio del chunk necessario. In generale, si può fare un'analogia della scrittura con il flusso d'acqua in barili. Ogni barile rappresenta un blocco di dati di 256 MB.
Cioè, un disco rappresenta una certa quantità di tali barili, quindi il volume del disco diviso per 256 MB. Ogni copia viene distribuita su un nodo, la seconda quasi parallelamente su un altro nodo, e così via… Se abbiamo tre repliche e ci sono dischi SSD per la cache (per la lettura e i registri di scrittura), la conferma della scrittura avverrà dopo la scrittura del registro nell'SSD, mentre il salvataggio parallelo dall'SSD continuerà su HDD, in modo quasi in background. In caso di tre repliche, il commit della scrittura avverrà dopo la conferma dall'SSD del terzo nodo. Potrebbe sembrare che la somma della velocità di scrittura di tre SSD possa essere divisa per tre e otterremmo la velocità di scrittura di una replica, ma la scrittura delle copie avviene parallelamente e la latenza della rete è solitamente superiore a quella degli SSD, e di fatto le prestazioni di scrittura dipenderanno dalla rete. Pertanto, per vedere i reali IOPS è necessario caricare correttamente l'intero Vstorage. , vale a dire testare il carico reale, e non la memoria e la cache, dove è necessario considerare la dimensione corretta del blocco dati, il numero di flussi, ecc.
Il registro menzionato sopra su SSD funziona in modo tale che, non appena i dati entrano, vengono immediatamente letti dal servizio e scritti su HDD. Ci sono più servizi di metadata (MDS) per cluster e il loro numero è determinato da un quorum che opera secondo l'algoritmo Paxos. Dal punto di vista del cliente, il punto di montaggio FUSE è una cartella di archiviazione del cluster, visibile contemporaneamente a tutti i nodi del cluster; ogni nodo ha montato il cliente secondo questo principio, quindi questo storage è accessibile a ciascun nodo.
Per le prestazioni di ciascuno degli approcci descritti sopra, è fondamentale, nella fase di pianificazione e distribuzione, configurare correttamente la rete, dove ci sarà bilanciamento grazie all'aggregazione e alla corretta scelta della larghezza di banda del canale di rete. Nell'aggregazione, è importante scegliere correttamente la modalità di hashing e le dimensioni dei frame. C'è anche una differenza significativa rispetto ai SDS descritti in precedenza: il fuse con la tecnologia fast path in Virtuozzo Storage. Che, oltre a un fuse aggiornato, a differenza delle altre soluzioni open source, aumenta significativamente gli IOPS e non limita la scalabilità orizzontale o verticale. In generale, rispetto alle architetture descritte sopra, questa appare più potente, ma per tale vantaggio è necessario acquistare licenze, a differenza di Ceph e Gluster.
In sintesi, possiamo evidenziare un top tre: il primo posto per prestazioni e affidabilità dell'architettura spetta a Virtuozzo Storage, il secondo a Ceph e il terzo a Gluster.
I criteri per cui è stato scelto Virtuozzo Storage: rappresenta un insieme ottimale di componenti architettonici, aggiornati per questo approccio Fuse con fast path, un set flessibile di configurazioni hardware, minore consumo di risorse e la possibilità di condivisione con compute (elaborazioni/virtualizzazioni), rendendolo perfettamente adatto per una soluzione iperconvergente, di cui fa parte. In seconda posizione Ceph, perché offre un'architettura più performante rispetto a Gluster, grazie alla gestione dei blocchi e a scenari più flessibili, con la possibilità di operare in cluster più ampi.
Tra i piani c'è l'intenzione di scrivere un confronto tra vSAN, Space Direct Storage, Vstorage e Nutanix Storage, testando Vstorage su hardware HPE, Huawei, e esplorando scenari di integrazione di Vstorage con sistemi di archiviazione esterni. Pertanto, se l'articolo vi è piaciuto, sarebbe utile ricevere i vostri feedback, che potrebbero rafforzare la motivazione per nuovi articoli tenendo conto delle vostre osservazioni e suggerimenti.
Fonte: habr.com
