Questo articolo è stato scritto per aiutarti a scegliere la soluzione più adatta e a comprendere le differenze tra SDS come Gluster, Ceph e Vstorage (Virtuozzo).
Nel testo sono presenti collegamenti ad articoli che approfondiscono ulteriormente determinati problemi, pertanto le descrizioni saranno il più concise possibile, focalizzandosi sui punti chiave senza inutili divagazioni e informazioni introduttive che potrai cercare autonomamente su Internet.
In realtà, gli argomenti trattati richiedono un certo tono di scrittura, ma nel mondo moderno sempre più persone non amano leggere molto))), quindi si può dare una lettura veloce per prendere una decisione, e se qualcosa non è chiaro, puoi seguire i link o cercare su Google le parole poco chiare))), e questo articolo funge da involucro trasparente per queste tematiche profonde, mettendo in evidenza i principali punti chiave di ogni 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 di SDS: Gluster o Ceph.
Gluster è composto da uno stack di traduttori – servizi che svolgono tutte le operazioni di distribuzione dei file, ecc. Brick – è il servizio che gestisce un singolo disco, Volume – è il volume (pool) che unisce questi brick. Successivamente, c'è il servizio di distribuzione dei file in gruppi grazie alla funzione DHT (distributed hash table). Non includeremo la spiegazione del servizio Sharding poiché nelle link seguenti sarà descritta la problematica ad esso correlata.
Quando si scrive, il file viene interamente collocato nel brick e una sua copia viene scritta in parallelo in un brick su un secondo server. Successivamente, un secondo file sarà registrato in un secondo gruppo di due brick (o più) su server diversi.
Se i file sono di dimensioni simili e il volume consiste solo in un gruppo, va tutto bene, ma in altre condizioni emergono dai descrittivi i seguenti problemi:
- lo spazio nei gruppi viene utilizzato in modo non uniforme, a seconda delle dimensioni dei file, e se non c'è spazio sufficiente in un gruppo per scrivere un file, riceverai un errore; il file non verrà scritto e non verrà ridistribuito in un altro gruppo;
- durante la scrittura di un file, l'IO avviene solo su un gruppo, mentre gli altri rimangono inattivi;
- non è possibile ottenere l'IO dell'intero volume durante la scrittura di un singolo file;
- e l'intera concezione sembra meno performante a causa dell'assenza di distribuzione dei dati su blocchi, dove è più semplice effettuare il bilanciamento e risolvere il problema della distribuzione uniforme, piuttosto che come ora il file si posi interamente in un brick.
Dalla descrizione ufficiale viene anche involontariamente la comprensione che Gluster funziona come un'archiviazione file sopra un tradizionale RAID hardware. Ci sono stati tentativi di sviluppare la frammentazione (Sharding) dei file in blocchi, ma tutto ciò è un'aggiunta che comporta perdite di prestazioni al già esistente approccio architetturale, oltre all'uso di componenti open-source con limitazioni di prestazioni come Fuse. Non ci sono servizi di metadata, il che limita le capacità di prestazioni e resilienza dell'archiviazione durante la distribuzione dei file su blocchi. Risultati di prestazioni migliori possono essere osservati nella configurazione “Distributed Replicated” e il numero di nodi deve essere almeno 6 per organizzare una replica affidabile di 3 con ottimale distribuzione del carico.
Queste conclusioni sono anche correlate alla descrizione dell'esperienza di utilizzo e nel confronto con , ed è presente anche una descrizione dell'esperienza che porta alla comprensione di questa configurazione più performante e più affidabile
Nell'immagine è mostrata la distribuzione del carico durante la scrittura di due file, dove le copie del primo file sono distribuite tra i primi tre server, che sono riuniti nel volume 0 gruppo, e tre copie del secondo file sono allocate nel secondo gruppo volume1 di tre server. Ogni server ha un disco.
La conclusione generale è che Gluster può essere utilizzato, ma con la consapevolezza che ci saranno limitazioni in termini di prestazioni e resilienza, che creano difficoltà in determinate condizioni di soluzioni iper-convergenti, dove le risorse sono necessarie anche per i carichi computazionali degli ambienti virtuali.
Ci sono anche alcuni indicatori di prestazioni di Gluster che possono essere raggiunti in determinate condizioni limitandosi in
Ceph
Ora esaminiamo Ceph dalle descrizioni dell'architettura che sono riuscito a C'è anche un confronto tra , dove si può subito capire che Ceph è preferibile distribuito su server separati, poiché i suoi servizi richiedono tutte le risorse dell'hardware in caso di carico.
Architettura è più complesso di Gluster e ci sono servizi come i servizi di metadata, ma l'intero stack di componenti è piuttosto complicato e non molto flessibile per l'uso in soluzioni di virtualizzazione. I dati vengono memorizzati in blocchi, il che sembra più produttivo, ma ci sono perdite e latenza nella gerarchia di tutti i servizi (componenti) in determinate condizioni di carico e di emergenza, per esempio nel seguente
Dalla descrizione dell'architettura, il cuore è rappresentato da CRUSH, che determina il luogo di memorizzazione dei dati. Successivamente c'è PG - questa è l'astrazione più complessa (gruppo logico) da comprendere. I PG sono necessari affinché CRUSH sia più efficace. L'obiettivo principale dei PG è raggruppare gli oggetti per ridurre il consumo di risorse, aumentare le prestazioni e la scalabilità. L'indirizzamento diretto di oggetti, singolarmente, senza raggrupparli in PG sarebbe molto costoso. OSD è il servizio per ogni singolo disco.
Un cluster può avere uno o più pool di dati di diversi scopi e con diverse impostazioni. I pool sono suddivisi in placement group. Nelle placement group vengono memorizzati gli oggetti a cui accedono i clienti. A questo livello logico si conclude, e inizia quello fisico, poiché a ogni placement group è associato un disco principale e diversi dischi replica (quanti dipende dal fattore di replica del pool). In altre parole, a livello logico, un oggetto è memorizzato in una specifica placement group, mentre a livello fisico - sui dischi a esso associati. I dischi possono essere fisicamente situati su nodi diversi o persino in data center diversi.
In this scheme, placement groups appear as a necessary level for the flexibility of the entire solution, but at the same time they also act as an unnecessary link in this chain, inevitably raising thoughts about performance loss. For example, when writing data, the system needs to break it down into these groups and then at the physical level onto the main disk and onto the replica disks. This means that the hash function works during the search and insertion of an object, but there is a side effect – there are very high costs and limitations on restructuring the hash (when adding or removing a disk). Another issue with the hash is its rigid data location, which cannot be changed. So, if a disk is under increased load, the system cannot choose not to write to it (by selecting another disk), because the hash function forces data to be placed according to this rule, regardless of how poorly the disk is performing. Therefore, Ceph uses a lot of memory when restructuring PGs in case of self-healing or storage expansion. The conclusion is that Ceph works well (albeit slowly), but only when there is no scaling, emergency situations, or updates.
There are, of course, options to improve performance through caching and cache tiers, but this requires good hardware, and there will still be losses. Overall, though, Ceph appears more attractive than Gluster for production. Additionally, using these products requires considering an important factor – a high level of competence, experience, and professionalism with a strong focus on Linux, as it is crucial to deploy, configure, and maintain everything correctly, which places even more responsibility and pressure on the administrator.
Vstorage
An even more interesting architecture is seen in , which can be used together with the hypervisor on the same nodes, on the same , but it is very important to configure everything correctly in order to achieve good performance. This means that deploying such a product straight from the box on any configuration without considering recommendations according to the architecture will be very easy, but not productive.
Cosa può coesistere per l'archiviazione accanto ai servizi del hypervisor kvm-qemu? Si tratta solo di pochi servizi, dove si trova una gerarchia di componenti ottimale e compatta: il servizio cliente montato tramite FUSE (modificato, non open source), il servizio di metadati MDS (Metadata service) e il servizio di blocchi dati Chunk service, che a livello fisico corrisponde a un disco e questo è tutto. Per velocità, è naturalmente ottimale utilizzare uno schema fault-tolerant in due repliche, ma se si utilizza la cache e i log su dischi SSD, la codifica resistente ai guasti (erase coding o raid6) può essere significativamente accelerata su uno schema ibrido o anche meglio su all flash. Con EC (erase coding) c'è un certo svantaggio: quando un blocco di dati viene modificato, è necessario ricalcolare le somme di parità. Per evitare perdite in questa operazione, Ceph scrive in EC in modo ritardato e ci possono essere problemi di performance con una certa richiesta, quando ad esempio è necessario leggere tutti i blocchi, mentre nel caso di Virtuozzo Storage la registrazione dei blocchi modificati avviene utilizzando l'approccio del 'file system strutturato a log', che minimizza i costi di calcolo della parità. Per farsi un'idea approssimativa delle opzioni di accelerazione del lavoro con e senza EC, c'è I numeri possono essere approssimativi e dipendono dal coefficiente di precisione del produttore dell'hardware, ma i risultati dei calcoli aiutano 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 una cooperazione vicina all'hypervisor.
C'è uno schema di confronto del consumo di risorse hardware da parte dei servizi Ceph e Virtuozzo storage.
Se in passato confrontare Gluster e Ceph era possibile attraverso vecchi articoli, utilizzando le righe più importanti di essi, con Virtuozzo è più complicato. Gli articoli su questo prodotto non sono molti e le informazioni possono essere reperite solo dalla documentazione su o in russo se si considera Vstorage come storage utilizzato in alcune soluzioni iperconvergenti in aziende come e Acronis.
Cercherò di aiutarti a descrivere questa architettura, quindi il testo sarà un po' più lungo, ma per capire la documentazione ci vorrà molto tempo, e la documentazione esistente può essere utilizzata solo come riferimento consultando l'indice o ricercando parole chiave.
Prendiamo in considerazione 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 client (servizio di punto di montaggio FUSE), ma il componente master del servizio metadati (MDS) ovviamente indirizzerà il client direttamente al servizio di chunk necessario (servizio di archiviazione blocchi CS), cioè il MDS non partecipa al processo di scrittura, ma semplicemente guida al servizio di chunk richiesto. In generale, si può fare un'analogia della scrittura con il versamento dell'acqua in botti. Ogni botte è un blocco di dati di 256 MB.
Quindi un disco è un certo numero di queste botti, ovvero la capacità del disco divisa per 256 MB. Ogni copia viene versata su un nodo, la seconda quasi parallelamente su un altro nodo, ecc... Se abbiamo tre repliche e ci sono dischi SSD, per la cache (per lettura e registrazione dei log), la conferma della scrittura avverrà dopo che il log è stato scritto su SSD, e lo scarico parallelo da SSD continuerà su HDD, come in modalità background. Nel 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 dei tre SSD possa essere divisa per tre, ottenendo così la velocità di scrittura di una singola replica, ma la scrittura delle copie avviene in parallelo e la latenza della rete è generalmente superiore a quella degli SSD, pertanto la prestazione di scrittura dipenderà dalla rete. Di conseguenza, per vedere reali IOPS è necessario caricare correttamente l'intero Vstorage secondo , cioè testare il carico reale, e non la memoria e la cache, dove è necessario considerare la giusta dimensione del blocco dati, il numero di thread, ecc.
Il registro menzionato sopra su SSD funziona in modo tale che non appena i dati vengono inseriti, vengono immediatamente letti dal servizio e scritti su HDD. Ci sono più servizi di metadati (MDS) per cluster e il loro numero è definito dal quorum che opera secondo l'algoritmo Paxos. Dal punto di vista del cliente, il punto di montaggio FUSE è una cartella di storage del cluster visibile a tutti i nodi. Ogni nodo ha un client montato in questo modo, quindi questo storage è accessibile a ciascun nodo.
Per le prestazioni di uno qualsiasi degli approcci sopra descritti, è fondamentale, nella fase di pianificazione e implementazione, configurare correttamente la rete, dove ci sarà un bilanciamento tramite aggregazione e una larghezza di banda di rete adeguatamente selezionata. Nell'aggregazione, è importante adeguare correttamente la modalità di hashing e le dimensioni dei frame. C'è anche una differenza significativa rispetto agli SDS descritti sopra, con FUSE e la tecnologia fast path in Virtuozzo Storage. A differenza delle altre soluzioni open source, questa offre un FUSE modernizzato che aumenta significativamente gli IOPS e consente di non limitarsi alla scalabilità orizzontale o verticale. In generale, rispetto alle architetture descritte, questa appare più potente, ma per tale beneficio è necessario acquistare licenze, a differenza di Ceph e Gluster.
In sintesi, il podio delle architetture per prestazioni e affidabilità vede al primo posto Virtuozzo Storage, al secondo Ceph e al terzo Gluster.
I criteri che hanno portato alla scelta di Virtuozzo Storage sono un insieme ottimale di componenti architetturali, un FUSE modernizzato con fast path, un set di configurazione hardware flessibile, minore consumo di risorse e la possibilità di condivisione con le attività computazionali (virtualizzazione), rendendolo perfettamente idoneo per una soluzione iperconvergente, di cui fa parte. Al secondo posto Ceph, poiché è un'architettura più performante rispetto a Gluster, grazie alla gestione di blocchi e a scenari più flessibili, oltre alla possibilità di operare in cluster di maggiori dimensioni.
Nel piano c'è la volontà di scrivere un confronto tra vSAN, Space Direct Storage, Vstorage e Nutanix Storage, testando Vstorage su hardware HPE, Huawei, oltre a scenari di integrazione di Vstorage con sistemi di archiviazione esterni. Quindi, se ti è piaciuto l'articolo, sarebbe utile ricevere i tuoi feedback, che potrebbero rafforzare la motivazione per nuovi articoli tenendo conto delle tue osservazioni e desideri.
Fonte: habr.com
