🥇 Soluzione iperconvergente AERODISK vAIR. Alla base c'è il file system ARDFS

Ciao, lettori di Habr. Con questo articolo inauguriamo un ciclo dedicato al sistema iperconvergente AERODISK vAIR, da noi sviluppato. Inizialmente volevamo spiegare tutto nella prima articolo, ma la struttura è piuttosto complessa, quindi ci occuperemo di essa a pezzettini.

Cominceremo raccontando la storia della creazione del sistema, approfondendo il file system ARDFS, che è alla base di vAIR, e discuteremo un po' del posizionamento di questa soluzione sul mercato russo.

Negli articoli futuri parleremo più in dettaglio dei diversi componenti architettonici (cluster, hypervisor, bilanciatore di carico, sistema di monitoraggio, ecc.), del processo di configurazione, affronteremo le questioni relative alle licenze, mostreremo separatamente i crash test e, naturalmente, discuteremo sul load testing e sul sizing. Dedicaremo anche un articolo alla versione community di vAIR.

AERODISK è una sorta di storia sulle storage system? O perché abbiamo iniziato a occuparci di hyperconvergenza?

L'idea di creare un nostro sistema iperconvergente è nata intorno al 2010. All'epoca non c'erano né Aerodisk né soluzioni simili (sistemi iperconvergenti commerciali) sul mercato. Il nostro obiettivo era: a partire da un insieme di server con dischi locali, interconnessi tramite protocollo Ethernet, creare uno storage distribuito e avviare virtual machines e una rete software. Tutto ciò doveva essere realizzato senza un sistema di storage (poiché non avevamo i fondi per un SAN, e all'epoca non avevamo ancora inventato il nostro).

Abbiamo provato 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, dopo aver risolto quel problema, abbiamo deciso di non sviluppare ulteriormente l'idea di trasformare il risultato del nostro lavoro in un prodotto completo.

Dopo quell'episodio ci siamo allontanati da questa idea, ma ci sentivamo comunque convinti che il problema fosse risolvibile e i benefici di tale soluzione fossero più che evidenti. In seguito, i prodotti HCI delle aziende straniere hanno solo confermato questa sensazione.

Nel corso del 2016, siamo tornati a questo compito nell'ambito della creazione di un prodotto completo. All'epoca non avevamo alcuna relazione con gli investitori, quindi ci siamo trovati a dover acquistare la nostra attrezzatura per lo sviluppo con fondi piuttosto limitati. Abbiamo cercato server e switch usati su Avito e ci siamo messi al lavoro.

Il nostro obiettivo iniziale era creare un file system, anche se semplice, ma di nostra proprietà, capace di distribuire automaticamente e uniformemente i dati in frammenti virtuali su un numero variabile di nodi nel cluster, interconnessi tramite Ethernet. Il file system doveva essere facilmente scalabile e indipendente da altri sistemi, cioè doveva operare come un semplice sistema di archiviazione.

La prima concezione di vAIR

Abbiamo scelto di non utilizzare soluzioni open source preconfezionate per creare uno storage distribuito (come Ceph, Gluster, Lustre e simili) a favore del nostro sviluppo, dato che avevamo già accumulato molta esperienza progettuale con esse. Certamente, queste soluzioni sono eccellenti di per sé, e prima di lavorare su Aerodisk abbiamo realizzato diversi progetti di integrazione con esse. Tuttavia, c’è una grande differenza tra soddisfare le esigenze specifiche di un cliente, formare il personale e, eventualmente, acquistare supporto da un grande fornitore, e l’ideazione di un prodotto scalabile che possa essere utilizzato per diverse applicazioni, che potremmo persino non conoscere come fornitori. Per quest'ultimo scopo, i prodotti open source esistenti non erano adatti, quindi abbiamo deciso di sviluppare noi stessi un sistema di file distribuiti.
Dopo due anni, un gruppo di sviluppatori (che combinavano il lavoro su vAIR con lo sviluppo di storage tradizionali Engine) ha raggiunto dei risultati concreti.

Entro il 2018 abbiamo sviluppato un semplice file system e lo abbiamo completato con l'interfaccia necessaria. Il sistema combinava i dischi fisici (locali) di diversi server in un unico pool piatto tramite un'interconnessione interna e li 'segmentava' in blocchi virtuali, dai quali venivano creati dispositivi a blocchi con vari livelli di tolleranza ai guasti, sui quali venivano create ed eseguite macchine virtuali tramite l'hypervisor KVM.

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

Questo prototipo sembrava valido (non visivamente, naturalmente, poiché non c'era ancora un'interfaccia grafica) 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 sviluppata l'architettura generale della soluzione, che non ha subito cambiamenti significativi fino ad oggi.

Entriamo nel file system ARDFS

ARDFS è alla base di vAIR, che fornisce uno storage dati distribuito e resiliente per l'intero cluster. Una delle (ma non l'unica) caratteristiche distintive di ARDFS è che non richiede alcun ulteriore di server dedicati sotto meta e gestione. Questo è stato progettato fin dall'inizio per semplificare la configurazione della soluzione e garantirne l'affidabilità.

Struttura di archiviazione

All'interno di tutti i nodi del cluster, ARDFS organizza un pool logico di tutto lo spazio disco disponibile. È importante comprendere che il pool non è ancora dati né spazio formattato, ma semplicemente un markup; quindi, qualsiasi nodo con vAIR installato, quando aggiunto al cluster, viene automaticamente incluso nel pool comune di ARDFS e le risorse disco diventano automaticamente condivise per l'intero cluster (e disponibili per la futura archiviazione dei dati). Questo approccio consente di aggiungere e rimuovere nodi al volo senza alcun serio impatto sul sistema già in funzionamento. Vale a dire, il sistema è molto facile da scalare a "mattoncini", aggiungendo o rimuovendo nodi nel cluster secondo necessità.

Sopra il pool ARDFS si aggiungono dischi virtuali (oggetti di archiviazione per le macchine virtuali), costruiti da blocchi virtuali di dimensione 4 megabyte. I dati vengono archiviati direttamente sui dischi virtuali. A livello dei dischi virtuali viene anche definito lo schema di tolleranza ai guasti.

Come si poteva già dedurre, per la tolleranza ai guasti del sottosistema di archiviazione non utilizziamo il concetto di RAID (Redundant array of independent Disks), ma utilizziamo RAIN (Redundant array of independent Nodes). Cioè, la tolleranza ai guasti viene misurata, automatizzata e gestita in base ai nodi, non ai dischi. I dischi, ovviamente, sono anch'essi oggetti di archiviazione, vengono monitorati come tutto il resto e si possono eseguire tutte le operazioni standard, incluso la creazione di un RAID hardware locale, ma il cluster opera effettivamente su nodi.

In situazioni in cui si desidera un RAID (ad esempio, uno scenario che supporta guasti multipli su piccoli cluster), non c'è nulla che impedisca di utilizzare controller RAID locali, implementando sopra uno storage espanso e un'architettura RAIN. Tale scenario è del tutto valido e supportato da noi, quindi ne parleremo nell'articolo sui casi d'uso standard di vAIR.

Schemi di tolleranza ai guasti dello storage

Ci possono essere due schemi di tolleranza ai guasti dei dischi virtuali in vAIR:

1) Il fattore di replica, o semplicemente replica, è un metodo di tolleranza ai guasti semplice "come un bastone e una corda". Viene eseguita la replica sincronizzata tra i nodi con un fattore di 2 (2 copie nel cluster) o 3 (3 copie, rispettivamente). L'RF-2 consente al disco virtuale di mantenere il servizio anche in caso di guasto di un nodo nel cluster, ma "consuma" metà della capacità utile, mentre l'RF-3 tollerarà il guasto di 2 nodi nel cluster, ma riserva già 2/3 della capacità utile per i propri bisogni. Questo schema ricorda molto RAID-1, ovvero un disco virtuale configurato in RF-2 è resistente al guasto di un qualsiasi nodo del cluster. In questo caso, i dati saranno al sicuro e anche le operazioni di input-output non si fermeranno. Quando il nodo guasto sarà di nuovo operativo, 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 con 8 MB di dati unici (utili) che opera su 4 nodi vAIR. È chiaro che nella realtà è improbabile avere un volume così ridotto, ma per rappresentare la logica di funzionamento di ARDFS, questo esempio è il più chiaro. AB rappresenta blocchi virtuali da 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" tra i nodi, evitando la sovrapposizione degli stessi dati su un nodo, ovvero la copia A1 non si troverà mai 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 si trova la copia B1), questa copia verrà automaticamente attivata su un nodo dove non è presente la copia della sua copia (cioè la copia B2).

Così, il disco virtuale (e la VM, di conseguenza) facilmente supererà il guasto di un nodo nello schema RF-2.

Lo schema di replicazione, nonostante la sua semplicità e affidabilità, presenta lo stesso problema del RAID1: poco spazio utile.

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

Nel processo di codifica, l'EC divide un blocco virtuale (di default 4 MB) in più «pezzi di dati» 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» dei «pezzi di parità» di dimensioni non superiori a una delle parti precedentemente divise. Durante la decodifica, l'EC genera i pezzi mancanti leggendo i dati «sopravvissuti» nell'intero cluster.

Ad esempio, un disco virtuale con schema EC 2 + 1, implementato su 4 nodi del cluster, può facilmente sopportare il guasto di un nodo nel cluster così come fa RF-2. Allo stesso tempo, le spese generali saranno inferiori, con un coefficiente di capacità utile di 2 per RF-2, mentre per EC 2+1 sarà 1,5.

In parole semplici, la questione fondamentale è che un blocco virtuale viene suddiviso in 2-8 "pezzi" (perché da 2 a 8, vedi sotto), e per questi pezzi vengono calcolati i “pezzi” di parità di corrispondente volume.

Di conseguenza, i dati e la parità vengono distribuiti uniformemente tra tutti i nodi del cluster. In questo modo, proprio come nella replica, ARDFS distribuisce automaticamente i dati tra i nodi in modo da evitare che dati identici (copia dei dati e parità) si trovino su un unico nodo, escludendo così la possibilità di perdere dati a causa della coincidenza di dati e parità su un nodo di archiviazione che potrebbe guastarsi.

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

I blocchi A e B sono suddivisi in due parti da 2 MB ciascuna (due perché 2+1), ossia A1+A2 e B1+B2. A differenza della replica, A1 non è una copia di A2, ma è un blocco virtuale A diviso in due parti, lo stesso vale per il blocco B. In totale otteniamo due set da 4 MB, ognuno contenente due pezzi da due megabyte. Inoltre, per ciascuno di questi set viene calcolata la parità con un volume non superiore a un pezzo (cioè 2 MB), ottenendo ulteriori +2 pezzi di parità (A-P e B-P). In totale abbiamo 4×2 dati + 2×2 di parità.

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

In caso di guasto di un nodo (supponiamo, il terzo), il blocco B1 andato perso verrà automaticamente ripristinato dalla parità B-P, che è memorizzata nel nodo n°2, e verrà attivato in un 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 si starà chiedendo:

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

E poi seguiranno le interessanti peculiarità del funzionamento di ARDFS.

Erasure coding con focus sulla flessibilità

Inizialmente abbiamo previsto uno schema EC X+Y piuttosto flessibile, dove X varia da 2 a 8 e Y da 1 a 8, ma sempre inferiore o uguale a X. Questo schema è studiato per garantire flessibilità. Aumentare il numero di pezzi di dati (X) in cui è suddiviso un blocco virtuale consente di ridurre le spese generali, aumentando così lo spazio utile.
Aumentare invece il numero di pezzi di parità (Y) aumenta l'affidabilità del disco virtuale. Maggiore è il valore di Y, più nodi nel cluster possono guastarsi. Naturalmente, un aumento del volume della parità riduce la capacità utile, ma è un sacrificio necessario per avere maggiore affidabilità.

La dipendenza delle prestazioni dagli schemi EC è quasi diretta: più "pezzi" ci sono, minori sono le prestazioni; qui, chiaramente, è necessaria una visione equilibrata.

Questo approccio consente agli amministratori di configurare in modo flessibile lo storage distribuito. All'interno del pool ARDFS è possibile utilizzare qualsiasi schema di tolleranza ai guasti e le loro combinazioni, cosa che consideriamo molto utile.

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

La tabella mostra che anche la combinazione più "robusta" EC 8+7, che consente la perdita fino a 7 nodi in un cluster, occupa meno spazio utile (1,875 contro 2) rispetto alla replica standard, ma offre una protezione sette volte superiore. Questo rende il meccanismo di protezione, sebbene più complesso, notevolmente più attraente in situazioni in cui è necessario garantire la massima affidabilità in caso di mancanza di spazio su disco. È importante capire che ogni "più" a X o Y comporta un costo aggiuntivo in termini di prestazioni, quindi nel triangolo tra affidabilità, economia e prestazioni, è fondamentale scegliere con molta attenzione. Per questa ragione, dedicheremo un articolo separato al sizing della codifica rimovibile.

Affidabilità e autonomia del file system

ARDFS viene eseguito localmente su tutti i nodi del cluster e li sincronizza tramite interfacce Ethernet dedicate. Un aspetto importante è che ARDFS sincronizza autonomamente non solo i dati, ma anche i metadati relativi allo storage. Durante lo sviluppo di ARDFS, abbiamo esaminato parallelamente diverse soluzioni esistenti e abbiamo scoperto che molte di esse effettuano la sincronizzazione dei metadati del file system utilizzando un DBMS distribuito esterno, che usiamo anche per la sincronizzazione, ma solo per le configurazioni, non per i metadati del FS (di questo e di altri sistemi correlati parleremo nel prossimo articolo).

La sincronizzazione dei metadati del FS utilizzando un DBMS esterno è sicuramente una soluzione funzionante, ma in tal caso la coerenza dei dati memorizzati su ARDFS dipenderebbe dal DBMS esterno e dal suo comportamento (che, a dirla tutta, è una signora piuttosto capricciosa), il che, a nostro avviso, è un aspetto negativo. Perché? Se i metadati del FS vengono danneggiati, si potrebbe dire addio anche ai dati stessi del FS, quindi abbiamo deciso di intraprendere un percorso più complesso ma affidabile.

Abbiamo sviluppato autonomamente il sottosistema di sincronizzazione dei metadati per ARDFS, che opera in assoluta indipendenza rispetto ai sottosistemi adiacenti. Nessun altro sottosistema può danneggiare i dati di ARDFS. A nostro avviso, questa è la soluzione più affidabile e corretta; solo il tempo dirà se sia veramente così. Inoltre, questo approccio porta con sé un ulteriore vantaggio. ARDFS può essere utilizzato in modo indipendente da vAIR, semplicemente come uno storage esteso, un'opzione che sicuramente utilizzeremo nei nostri prodotti futuri.

Di conseguenza, sviluppando ARDFS, abbiamo ottenuto un file system flessibile e affidabile, che offre la scelta di risparmiare sulla capacità o di dedicare tutto alle prestazioni, oppure di rendere lo storage super affidabile a un costo moderato, riducendo al contempo le esigenze prestazionali.

Insieme a una politica di licenza semplice e a un modello di fornitura flessibile (anticipando che la licenza di vAIR è basata sui nodi e viene fornita sia come software che come PAC), questo consente di adattare con precisione la soluzione alle diverse esigenze dei clienti, mantenendo facilmente questo equilibrio in futuro.

A chi serve questa meraviglia?

Da un lato, si può dire che nel mercato ci sono già attori con soluzioni serie nel campo dell'iperconvergenza, e a cui stiamo cercando di accedere. Sembra che questa affermazione sia vera, MA...

Dall'altro lato, uscendo sul campo e comunicando 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 ci fossero soluzioni di questo tipo, in altri sembrava costoso, in alcuni ci sono stati test falliti di soluzioni alternative, e in altri casi l'acquisto è addirittura vietato a causa delle sanzioni. Insomma, il campo si è rivelato vergine, quindi abbiamo deciso di portare avanti la nostra iniziativa)))

Quando le soluzioni tradizionali sono migliori dell'iperconvergenza?

Durante il nostro lavoro con il mercato, ci chiedono spesso quando sia meglio utilizzare un sistema tradizionale rispetto all'iperconvergenza. Molte aziende produttrici di sistemi iperconvergenti (soprattutto quelle che non hanno nel loro portafoglio sistemi tradizionali) dicono: «I sistemi di archiviazione tradizionali stanno perdendo rilevanza, solo iperconvergenza!». Questa è una dichiarazione audace, ma non riflette completamente la realtà.

A dire il vero, il mercato dei sistemi di archiviazione tradizionali si sta realmente spostando verso l'iperconvergenza e soluzioni simili, ma c'è sempre un 'ma'.

In primo luogo, non è così semplice riprogettare i data center e le infrastrutture IT costruiti secondo schemi tradizionali con storage a blocchi, quindi la modernizzazione e l'adeguamento di tali infrastrutture rappresentano un'eredità di circa 5-7 anni.

In secondo luogo, la maggior parte delle infrastrutture attualmente in costruzione (riferendosi alla Federazione Russa) segue schemi tradizionali con l'uso di storage a blocchi. Non è che non si conosca il hyper-converged, ma il mercato dell'hyper-converged è nuovo, le soluzioni e gli standard non sono ancora consolidati, gli IT staff non sono ancora formati, ci sono poche esperienze, e i data center devono essere costruiti qui e ora. Questa tendenza continuerà per altri 3-5 anni (e poi ci sarà ancora un'eredità, vedi punto 1).

In terzo luogo, c'è un limite tecnico puramente legato a piccole latenze aggiuntive di 2 millisecondi per la scrittura (escludendo, naturalmente, la cache locale), che rappresentano il prezzo da pagare per lo storage distribuito.

E non dimentichiamo l'uso di grandi server fisici, che richiedono un'espansione verticale del sistema di archiviazione.

Ci sono molte situazioni necessarie e popolari in cui le soluzioni di storage condiviso si comportano meglio delle soluzioni iperconvergenti. Certamente, non saranno d'accordo con noi quei produttori che non hanno soluzioni di storage condiviso nel loro portafoglio, ma siamo pronti a discutere con argomentazioni solide. Naturalmente, come sviluppatori di entrambi i prodotti, in una delle prossime pubblicazioni, faremo un confronto tra storage condiviso e soluzioni iperconvergenti, in cui mostreremo chiaramente in quali condizioni ciascuno è migliore.

In quali situazioni le soluzioni iperconvergenti funzioneranno meglio delle soluzioni di storage condiviso?

Sulla base dei punti sopra, si possono trarre tre conclusioni ovvie:

Laddove ulteriori 2 millisecondi di latenza in scrittura, che si verificano costantemente in qualsiasi ambiente produttivo (non stiamo parlando di test sintetici, dove è possibile mostrare anche nanosecondi), siano critici, le soluzioni iperconvergenti possono andare bene.
Laddove il carico proveniente da grandi server fisici può essere trasformato in molte piccole risorse virtuali e distribuito su nodi, anche le soluzioni iperconvergenti si comporteranno bene.
Laddove la scalabilità orizzontale è più prioritaria rispetto a quella verticale, anche le soluzioni iperconvergenti si integreranno perfettamente.

Quali sono queste soluzioni?

Tutti i servizi infrastrutturali standard (servizio directory, posta, DMS, server file, sistemi ERP e BI di piccole o medie dimensioni, ecc.). Li chiamiamo "calcolo condiviso".
Infrastruttura dei fornitori cloud, dove è necessario espandere rapidamente in modo standardizzato in orizzontale e creare facilmente un gran numero di macchine virtuali per i clienti.
Infrastruttura scrivanie virtuali (VDI), dove molte piccole macchine virtuali degli utenti vengono avviate e galleggiano tranquillamente all'interno di un cluster uniforme.
Reti filiali, dove in ciascuna filiale è necessaria un'infrastruttura standard, resiliente e a basso costo composta da 15-20 macchine virtuali.
Qualsiasi calcolo distribuito (servizi big data, ad esempio). Dove il carico si espande "in orizzontale" piuttosto che "in profondità".
Ambienti di test, dove sono ammesse piccole latenze aggiuntive, ma ci sono limitazioni di budget, poiché si tratta di test.

Attualmente, è per queste esigenze che abbiamo creato AERODISK vAIR e su di esse ci concentriamo (fino ad ora con successo). Potrebbe cambiare presto, poiché il mondo non si ferma.