🥇 Soluzione iperconvergente AERODISK vAIR. La base è il sistema di file ARDFS

Ciao, lettori di Habr. Con questo articolo apriamo un ciclo che parlerà del sistema iperconvergente AERODISK vAIR sviluppato da noi. Inizialmente volevamo trattare tutto sin da subito, ma il sistema è piuttosto complesso, quindi lo affronteremo a pezzi.

Iniziamo il racconto dalla storia della creazione del sistema, approfondiremo il file system ARDFS, che è la base di vAIR, e discuteremo un po' del posizionamento di questa soluzione nel mercato russo.

Negli articoli successivi parleremo più dettagliatamente dei vari componenti architetturali (cluster, ipervisore, bilanciatore di carico, sistema di monitoraggio, ecc.), del processo di configurazione, affronteremo le questioni relative alle licenze, presenteremo test di stress e, naturalmente, scriveremo riguardo al testing delle prestazioni e al sizing. Dedicheremo anche un articolo specifico alla versione community di vAIR.

AERODISK è una sorta di storia sulle SAN? O perché abbiamo iniziato a occuparci di iperconvergenza?

L'idea di creare la nostra iperconvergenza ci è venuta attorno al 2010. All'epoca non esistevano né AERODISK né soluzioni simili (sistemi iperconvergenti commerciali) sul mercato. Il nostro compito era il seguente: trasformare un insieme di server con dischi locali, connessi tramite interconnect in protocollo Ethernet, in uno storage distribuito e avviare lì macchine virtuali e una rete software. Tutto questo doveva essere realizzato senza SAN (perché non avevamo fondi per le SAN e le relative infrastrutture, e non avevamo ancora inventato la nostra SAN).

Abbiamo sperimentato molte soluzioni open source e alla fine abbiamo risolto il problema, ma la soluzione era molto complessa e difficile da replicare. Inoltre, era una di quelle soluzioni del tipo 'Funziona? Non toccare!'. Pertanto, avendo risolto quel problema, non abbiamo proseguito nello sviluppo dell'idea di trasformare il risultato del nostro lavoro in un prodotto a pieno titolo.

Dopo quel caso ci siamo allontanati dall'idea, ma non ci ha comunque mai abbandonato la sensazione che quel problema fosse affrontabile e che i benefici di una simile soluzione fossero più che evidenti. In seguito, i prodotti HCI lanciati da aziende straniere hanno solo confermato questa sensazione.

Pertanto, nel mezzo del 2016, abbiamo ripreso questo compito nel contesto della creazione di un prodotto completo. All'epoca non avevamo ancora alcuna relazione con gli investitori, quindi abbiamo dovuto acquistare il nostro stand di sviluppo con i nostri pochi soldi. Dopo aver cercato su Avito server e switch usati, ci siamo messi al lavoro.

Il compito iniziale principale era la creazione di un proprio, anche se semplice, sistema di file che potesse distribuire automaticamente e uniformemente i dati sotto forma di blocchi virtuali su un numero n di nodi del cluster, uniti tra loro tramite interconnessione Ethernet. Inoltre, il sistema di file doveva essere scalabile e facilmente indipendente da sistemi adiacenti, ovvero doveva essere trasferibile da vAIR come semplice 'storage'.

Il primo concetto di vAIR

Abbiamo deliberatamente rinunciato all'uso di soluzioni open source pronte per organizzare uno storage distribuito (come Ceph, Gluster, Lustre e simili) a favore dello sviluppo interno, poiché avevamo già accumulato molta esperienza progettuale con essi. È innegabile che queste soluzioni siano eccellenti e, prima di lavorare su Aerodisk, abbiamo realizzato diversi progetti di integrazione con esse. Ma un conto è realizzare un compito specifico per un cliente, formare il personale e, forse, acquistare il supporto di un grande fornitore; un altro conto è creare un prodotto facilmente replicabile che sarà utilizzato per compiti diversi, di cui, come fornitore, potremmo anche non sapere nulla. Per questo secondo obiettivo, i prodotti open source esistenti non erano adatti, quindi abbiamo deciso di sviluppare noi stessi il sistema di file distribuito.
Dopo due anni, grazie all'impegno di alcuni sviluppatori (che combinavano il lavoro su vAIR con quello sulla classica SAN Engine), abbiamo raggiunto un risultato significativo.

Entro il 2018 avevamo scritto un sistema di file molto semplice e l'avevamo completato con il necessario supporto. Il sistema univa, tramite interconnessione interna, dischi fisici (locali) provenienti da diversi server in un unico pool piatto e li 'tagliava' in blocchi virtuali; successivamente, dai blocchi virtuali venivano creati dispositivi a blocchi con vari livelli di tolleranza ai guasti, su cui venivano create ed eseguite macchine virtuali tramite l'ipercontrollore KVM.

Non ci siamo particolarmente preoccupati del nome del file system e lo abbiamo chiamato ARDFS (indovinate cosa significa))

Questo prototipo appariva bene (non visivamente, ovviamente, poiché non c'era ancora design visivo) e mostrava buoni risultati in termini di prestazioni e scalabilità. Dopo il primo risultato reale, abbiamo dato il via a questo progetto, organizzando un ambiente di sviluppo completo e un team separato che si occupava solo di vAIR.

Proprio in quel periodo è stata matura l'architettura generale della soluzione, che fino ad oggi non ha subito cambiamenti significativi.

Immergiamoci nel file system ARDFS

ARDFS è la base di vAIR, che fornisce un'archiviazione dei dati distribuita e tollerante ai guasti per l'intero cluster. Una delle (ma non l'unica) caratteristiche distintive di ARDFS è che non utilizza alcuna forma di dei server dedicati sottosistema e gestione. Era stato concepito fin dall'inizio per semplificare la configurazione della soluzione e per garantirne l'affidabilità.

Struttura di archiviazione

All'interno di tutti i nodi del cluster, ARDFS organizza un pool logico di tutta la capacità disco disponibile. È importante comprendere che un pool non è ancora dati e nemmeno uno spazio formattato, ma semplicemente una segmentazione, cioè qualsiasi nodo con vAIR installato, aggiunto al cluster, viene automaticamente integrato nel pool comune di ARDFS e le risorse disco diventano automaticamente condivise per l'intero cluster (e disponibili per future archiviazioni di dati). Questo approccio consente di aggiungere e rimuovere nodi al volo senza alcun impatto serio sul sistema già funzionante. Cioè, il sistema è molto facile da scalare

Sopra il pool di ARDFS vengono aggiunti dischi virtuali (oggetti di archiviazione per le macchine virtuali), costruiti da blocchi virtuali delle dimensioni di 4 megabyte. I dati sono memorizzati direttamente sui dischi virtuali. A livello di dischi virtuali viene definito anche uno schema di tolleranza ai guasti.

Come si può già intuire, per garantire l'affidabilità del sistema di archiviazione, non utilizziamo il concetto di RAID (Array ridondante di dischi indipendenti), ma utilizziamo RAIN (Array ridondante di nodi indipendenti). Vale a dire, l'affidabilità è misurata, automatizzata e gestita in base ai nodi, e non ai dischi. I dischi, senza dubbio, sono anch'essi oggetti di archiviazione; vengono monitorati come tutto il resto e con essi è possibile eseguire tutte le operazioni standard, inclusa la creazione di un RAID hardware locale, ma il cluster opera proprio sui nodi.

In una situazione in cui si desidera fortemente RAID (ad esempio, in uno scenario che supporta guasti multipli su piccoli cluster), nulla impedisce di utilizzare controller RAID locali e sopra creare uno storage distribuito e un'architettura RAIN. Questo scenario è assolutamente pratico e supportato da noi, quindi ne parleremo nell'articolo sui casi d'uso tipici di vAIR.

Schemi di affidabilità dello storage

Possono esserci due schemi di affidabilità per i dischi virtuali in vAIR:

1) Fattore di replicazione o semplicemente replicazione – questo metodo di affidabilità è semplice "come un bastone e una corda". Viene eseguita una replicazione sincrona tra i nodi con un fattore di 2 (2 copie nel cluster) o 3 (3 copie, rispettivamente). RF-2 consente al disco virtuale di resistere al guasto di un nodo nel cluster, ma "consuma" metà della capacità utile, mentre RF-3 resisterà al guasto di 2 nodi nel cluster, ma riserverà già 2/3 della capacità utile per i propri bisogni. Questo schema assomiglia molto a RAID-1, quindi un disco virtuale configurato in RF-2 è resistente al guasto di qualsiasi nodo del cluster. In questo caso, i dati saranno al sicuro e anche l'input/output non si fermerà. Quando il nodo guasto tornerà in funzione, inizierà il ripristino/sincronizzazione automatica dei dati.

Di seguito sono riportati esempi di distribuzione dei dati RF-2 e RF-3 in condizioni normali e in situazioni di guasto.

Abbiamo una macchina virtuale di 8 MB di dati unici (utili) che opera su 4 nodi vAIR. È chiaro che nella realtà un volume così ridotto è difficile da trovare, ma per uno schema che rifletta la logica di funzionamento di ARDFS, questo esempio è il più chiaro. AB sono blocchi virtuali di 4 MB contenenti dati unici della macchina virtuale. Con RF-2 vengono create due copie di questi blocchi A1+A2 e B1+B2, rispettivamente. Questi blocchi vengono "distribuiti" sui nodi, evitando la sovrapposizione degli stessi dati su un nodo, cioè la copia A1 non sarà presente sullo stesso nodo della copia A2. Lo stesso vale per B1 e B2.

In caso di guasto di uno dei nodi (ad esempio, il nodo n. 3, dove è presente la copia B1), questa copia viene automaticamente attivata su un nodo dove non è presente una copia della sua copia (cioè la copia B2).

Pertanto, il disco virtuale (e la VM, di conseguenza) può facilmente resistere al guasto di un nodo nel schema RF-2.

Lo schema di replica, pur nella sua semplicità e affidabilità, presenta la stessa problematica del RAID1: poco spazio utile.

2) L'errore di codifica o 'erasure coding' (noto anche come 'coding ridondante', 'coding cancellativo' o 'codice di ridondanza') è stato creato proprio per risolvere il problema sopra. EC è uno schema di ridondanza che garantisce un'alta disponibilità dei dati con minori costi di archiviazione rispetto alla replica. Il principio di funzionamento di questo meccanismo è simile a RAID 5, 6, 6P.

Nel processo di codifica, l'EC suddivide il blocco virtuale (per impostazione predefinita 4 MB) in diversi 'pezzi di dati' più piccoli, a seconda dello schema EC (ad esempio, lo schema 2+1 divide ogni blocco da 4 MB in 2 pezzi da 2 MB). Successivamente, il processo genera per i 'pezzi di dati' 'pezzi di parità' della dimensione massima di una delle parti precedentemente suddivise. Durante la decodifica, l'EC genera i pezzi mancanti leggendo i dati 'sopravvissuti' in tutto il cluster.

Ad esempio, un disco virtuale con schema EC 2 + 1, implementato su 4 nodi di un cluster, resisterà tranquillamente al guasto di un nodo nel cluster, proprio come RF-2. In questo caso, i costi operativi saranno inferiori: il rapporto di utilizzo utile in RF-2 è 2, mentre in EC 2+1 sarà 1,5.

In parole semplici, il concetto è che il blocco virtuale viene suddiviso in 2-8 'pezzi' (il motivo per cui da 2 a 8 lo si vedrà più avanti) e per questi pezzi vengono calcolati 'pezzi' di parità di volume simile.

Alla fine, i dati e la parità vengono distribuiti uniformemente su tutti i nodi del cluster. Inoltre, come per la replica, ARDFS distribuisce automaticamente i dati sui nodi in modo da evitare di memorizzare dati identici (copia dei dati e della loro parità) su un unico nodo, per escludere la possibilità di perdere dati poiché i dati e la loro parità si troverebbero improvvisamente su un unico nodo di archiviazione, che si guasta.

Di seguito un esempio, con la stessa macchina virtuale da 8 MB e 4 nodi, ma già con uno schema EC 2+1.

I blocchi A e B sono divisi in due pezzi ciascuno da 2 MB (in due perché 2+1), cioè A1+A2 e B1+B2. Diversamente dalla replica, A1 non è una copia di A2, è un blocco virtuale A, suddiviso in due parti, lo stesso vale per il blocco B. Pertanto otteniamo due set da 4MB, ognuno dei quali contiene due pezzi da due megabyte. Successivamente, per ciascuno di questi set viene calcolata la parità con un volume non superiore a un pezzo (cioè 2 MB), ottenendo ulteriormente + 2 pezzi di parità (A-P e B-P). In totale abbiamo 4×2 dati + 2×2 parità.

Successivamente, i pezzi vengono "distribuiti" sui nodi in modo che i dati non si sovrappongano alla loro parità. Cioè, A1 e A2 non saranno memorizzati nello stesso nodo di A-P.

In caso di guasto di un nodo (supponiamo, anche il terzo), il blocco B1 sarà automaticamente ripristinato dalla parità B-P, che è memorizzata sul nodo n. 2, e sarà attivato sul nodo dove non è presente la parità B, cioè il pezzo B-P. In questo esempio, si tratta del nodo n. 1.

Sono sicuro che il lettore avrà una domanda:

"Tutto ciò che hai descritto è già stato implementato dai concorrenti e in soluzioni open source, qual è la differenza della tua implementazione EC in ARDFS?"

E poi ci saranno interessanti caratteristiche del funzionamento di ARDFS.

Erasure coding con un focus sulla flessibilità

Inizialmente abbiamo previsto uno schema di EC piuttosto flessibile X+Y, dove X varia da 2 a 8 e Y da 1 a 8, ma sempre minore o uguale a X. Questo schema è previsto per garantire flessibilità. Aumentando il numero di pezzi di dati (X) in cui è suddiviso il blocco virtuale, si riducono i costi generali, cioè si aumenta lo spazio utile.
Aumentando il numero di pezzi di parità (Y), si aumenta l'affidabilità del disco virtuale. Maggiore è il valore di Y, maggiore è il numero di nodi del cluster che possono guastarsi. Ovviamente, aumentando il volume della parità si riduce la capacità utile, ma questo è il prezzo da pagare per l'affidabilità.

La dipendenza delle prestazioni dagli schemi EC è quasi diretta: più «pezzi» ci sono, minori saranno le prestazioni, qui è chiaro che ci vuole uno sguardo equilibrato.

Questo approccio consente agli amministratori di configurare in modo flessibile lo storage distribuito. All'interno del pool ARDFS possono essere utilizzati qualsiasi schema di tolleranza ai guasti e le loro combinazioni, il che è, a nostro avviso, molto utile.

Di seguito è riportata una tabella di confronto di diversi schemi RF e EC (non tutti i possibili).

Dalla tabella si evince che anche la combinazione EC 8+7, che consente di perdere fino a 7 nodi simultaneamente nel cluster, «consuma» meno spazio utile (1,875 contro 2) rispetto alla replica standard, proteggendo allo stesso tempo 7 volte meglio. Questo rende questo meccanismo di protezione, sebbene più complesso, notevolmente più attraente in situazioni in cui è necessario garantire la massima affidabilità in caso di scarsità di spazio su disco. È importante comprendere che ogni «più» a X o Y comporterà un ulteriore costo sulle prestazioni, quindi nel triangolo tra affidabilità, economia e prestazioni bisogna fare una scelta molto attenta. Per questo motivo, dedicheremo un articolo separato al dimensionamento della codifica del cancellamento.

Affidabilità e autonomia del file system.

ARDFS viene avviato localmente su tutti i nodi del cluster e sincronizza i propri mezzi attraverso interfacce Ethernet dedicate. Un aspetto importante è che ARDFS sincronizza autonomamente non solo i dati, ma anche i metadati relativi allo storage. Durante il lavoro su ARDFS, abbiamo contemporaneamente esaminato una serie di soluzioni esistenti e abbiamo scoperto che molti fanno la sincronizzazione dei metadati del file system tramite un DBMS distribuito esterno, che utilizziamo anch'esso per la sincronizzazione, ma solo delle configurazioni e non dei metadati del FS (di questo e di altri sistemi adiacenti parleremo nel prossimo articolo).

La sincronizzazione dei metadati del FS tramite un DBMS esterno è sicuramente una soluzione valida, ma in tal caso la consistenza dei dati memorizzati su ARDFS dipenderebbe dal DBMS esterno e dal suo comportamento (e, diciamolo chiaramente, è una signora capricciosa), il che a nostro avviso è negativo. Perché? Se i metadati del FS venissero danneggiati, anche i dati stessi del FS potrebbero dire "addio", quindi abbiamo deciso di intraprendere un percorso più complesso ma affidabile.

Abbiamo sviluppato autonomamente il sottosistema di sincronizzazione dei metadati per ARDFS, e vive completamente indipendente dai sottosistemi adiacenti. Cioè, nessun altro sottosistema può danneggiare i dati di ARDFS. A nostro avviso, questo è il percorso più affidabile e corretto, e se sia veramente così, lo dirà il tempo. Inoltre, tale approccio presenta un ulteriore vantaggio. ARDFS può essere utilizzato indipendentemente da vAIR, semplicemente come un archivio espanso, cosa che certamente utilizzeremo nei prodotti futuri.

Di conseguenza, sviluppando ARDFS, abbiamo ottenuto un file system flessibile e affidabile, che offre la scelta su dove risparmiare in capacità o dedicare tutto alla performance, o rendere l'archivio super affidabile a un costo moderato, riducendo però le esigenze prestazionali.

Insieme a una semplice politica di licenza e a un modello di fornitura flessibile (anticipando, vAIR è licenziato per nodi e fornito sia come software che come PAC), questo consente di adattare molto precisamente la soluzione alle più varie esigenze dei clienti e di mantenere facilmente questo equilibrio in futuro.

A chi serve questa meraviglia?

Da un lato, si potrebbe dire che ci sono già attori sul mercato con soluzioni serie nel campo dell'iperconvergenza, e dove, in fondo, stiamo cercando di inserirci. Sembra che questa affermazione sia corretta, MA...

D'altro canto, uscendo "sul campo" e interagendo con i clienti, noi e i nostri partner vediamo che non è affatto così. Ci sono molte esigenze per l'iperconvergenza, in alcuni casi le persone semplicemente non sapevano che queste soluzioni esistessero, in altri sembrava costoso, ci sono stati test fallimentari di soluzioni alternative, e in alcuni casi addirittura è vietato acquistare, a causa delle sanzioni. In generale, il campo si è rivelato inesplorato, quindi abbiamo deciso di coltivare l'ignoto))).

Quando è meglio avere un SCD rispetto a un GCS?

Nel corso del nostro lavoro con il mercato, ci viene spesso chiesto quando sia meglio utilizzare lo schema classico con lo storage a disco (SХД) e quando optare per le soluzioni iperconvergenti. Molte aziende produttrici di GКС (soprattutto quelle che non hanno nello loro offerta SХД) affermano: «L'SХД è obsoleta, solo soluzione iperconvergente!». È un'affermazione audace, ma non riflette del tutto la realtà.

A dire il vero, il mercato SХД sta davvero migrando verso l'iperconvergente e soluzioni simili, ma c'è sempre un «ma».

In primo luogo, i data center e le infrastrutture IT costruiti secondo lo schema classico con SХД non possono essere semplicemente riconvertiti, quindi la modernizzazione e l'espansione di tali infrastrutture rappresentano un'eredità di altri 5-7 anni.

In secondo luogo, le infrastrutture che vengono attualmente costruite nella maggior parte (si fa riferimento alla RF) sono realizzate secondo lo schema classico con l'uso della SХД e non perché le persone non conoscano l'iperconvergente, ma perché il mercato dell'iperconvergente è nuovo, le soluzioni e gli standard non sono ancora consolidati, gli IT manager non sono ancora formati, c'è poca esperienza, e bisogna costruire i data center qui e ora. Questa tendenza durerà ancora per 3-5 anni (e poi ci sarà ancora eredità, vedere punto 1).

In terzo luogo, esiste un vincolo tecnico puro con piccoli ritardi aggiuntivi di 2 millisecondi nella scrittura (senza considerare la cache locale, ovviamente), che sono il prezzo per l'archiviazione distribuita.

E non dimentichiamo l'uso di grandi server fisici, che amano la scalabilità verticale del sottosistema di archiviazione.

Ci sono molte attività necessarie e popolari, dove la SХД si comporta meglio rispetto alla GКС. Certamente, chi produce GКС e non ha SХД nella propria offerta non sarà d'accordo, ma siamo pronti a discutere in modo argomentato. Naturalmente, come sviluppatori di entrambi i prodotti, in una delle prossime pubblicazioni condurremo un confronto tra SХД e GКС, dove dimostreremo chiaramente le condizioni ottimali per ciascuna soluzione.

E dove le soluzioni iperconvergenti funzioneranno meglio della SХД?

Partendo dalle affermazioni precedenti, si possono trarre tre conclusioni ovvie:

Laggiù, dove i 2 millisecondi di ritardo aggiuntivi nella scrittura, che si verificano stabilmente in qualsiasi sistema produttivo (al momento non stiamo parlando di sintesi, poiché in sintesi si possono mostrare anche i nanosecondi), sono non critici, l'iperconvergente sarà appropriato.
Dove il carico di grandi server fisici può essere trasformato in molte piccole macchine virtuali e distribuito su nodi, lì l'iperconvergenza si inserirà bene.
Dove la scalabilità orizzontale è più prioritaria rispetto a quella verticale, lì anche l'iperconvergenza si adatterà perfettamente.

Quali sono queste soluzioni?

Tutti i servizi infrastrutturali standard (servizio directory, email, gestione documentale, server file, sistemi ERP e BI piccoli o medi, ecc.). Noi li chiamiamo «computazione generale».
L'infrastruttura dei fornitori di servizi cloud, dove è necessario espandersi rapidamente e in modo standardizzato in orizzontale e creare facilmente un gran numero di macchine virtuali per i clienti.
Infrastruttura desktop virtuali (VDI), dove molte piccole macchine virtuali per gli utenti vengono avviate e navigano tranquillamente all'interno di un cluster uniforme.
Reti filiali, dove ogni filiale necessita di un'infrastruttura standard, resistente ai guasti, ma al tempo stesso economica, composta da 15-20 macchine virtuali.
Qualsiasi computazione distribuita (servizi big data, per esempio). Dove il carico non va «in profondità», ma «in larghezza».
Ambienti di test, dove sono ammesse piccole latenze aggiuntive, ma ci sono vincoli di budget, poiché si tratta di test.

Attualmente, per queste attività abbiamo realizzato AERODISK vAIR e ci concentriamo precisamente su di esse (fino ad ora con successo). Potrebbe cambiare presto, poiché il mondo non si ferma.