Ciao, lettori di Habr. Con questo articolo apriamo una serie che parlerà del sistema iperconvergente AERODISK vAIR che abbiamo sviluppato. Inizialmente volevamo raccontare tutto nel primo articolo, ma il sistema è piuttosto complesso, quindi mangeremo l'elefante in alcune parti.
Cominciamo la storia con la storia della creazione del sistema, approfondiamo il file system ARDFS, che è la base di vAIR, e parliamo anche un po' del posizionamento di questa soluzione sul mercato russo.
Nei prossimi articoli parleremo più in dettaglio dei diversi componenti dell'architettura (cluster, hypervisor, bilanciatore del carico, sistema di monitoraggio, ecc.), del processo di configurazione, solleveremo problemi di licenza, mostreremo separatamente i crash test e, ovviamente, scriveremo sui test di carico e dimensionamento. Dedicheremo anche un articolo a parte alla versione community di vAIR.
Aerodisk è una storia sui sistemi di storage? Oppure perché abbiamo iniziato a realizzare l’iperconvergenza?
Inizialmente, l’idea di creare la nostra iperconvergenza ci è venuta intorno al 2010. A quel tempo sul mercato non esistevano né Aerodisk né soluzioni simili (sistemi iperconvergenti boxed commerciali). Il nostro compito era il seguente: da un insieme di server con dischi locali, uniti da un'interconnessione tramite protocollo Ethernet, è stato necessario creare uno storage esteso e lì avviare macchine virtuali e una rete software. Tutto ciò doveva essere implementato senza sistemi di archiviazione (perché semplicemente non c'erano soldi per i sistemi di archiviazione e il relativo hardware e non avevamo ancora inventato i nostri sistemi di archiviazione).
Abbiamo provato molte soluzioni open source e alla fine abbiamo risolto questo problema, ma la soluzione era molto complessa e difficile da ripetere. Inoltre, questa soluzione rientrava nella categoria “Funziona? Non toccare! Pertanto, risolto quel problema, non abbiamo sviluppato ulteriormente l’idea di trasformare il risultato del nostro lavoro in un prodotto a tutti gli effetti.
Dopo quell'incidente ci siamo allontanati da questa idea, ma avevamo ancora la sensazione che il problema fosse completamente risolvibile e che i vantaggi di tale soluzione fossero più che evidenti. Successivamente, i prodotti HCI rilasciati da aziende straniere non hanno fatto altro che confermare questa sensazione.
Pertanto, a metà del 2016, siamo tornati a questo compito come parte della creazione di un prodotto a tutti gli effetti. A quel tempo non avevamo ancora rapporti con gli investitori, quindi abbiamo dovuto acquistare uno stand di sviluppo con i nostri soldi non molto grandi. Dopo aver raccolto server e switch usati su Avito, ci siamo messi al lavoro.
Il compito iniziale principale era creare il nostro, anche se semplice, ma il nostro file system, in grado di distribuire automaticamente e uniformemente i dati sotto forma di blocchi virtuali sull'ennesimo numero di nodi del cluster, collegati da un'interconnessione via Ethernet. Allo stesso tempo, il FS dovrebbe scalare bene e facilmente ed essere indipendente dai sistemi adiacenti, vale a dire essere alienato da vAIR sotto forma di “semplice impianto di stoccaggio”.
Primo concetto vAIR
Abbiamo deliberatamente abbandonato l'uso di soluzioni open source già pronte per l'organizzazione dello storage allungato (ceph, gluster, lustre e simili) a favore del nostro sviluppo, poiché avevamo già molta esperienza di progetto con esse. Naturalmente, queste soluzioni stesse sono eccellenti e, prima di lavorare su Aerodisk, abbiamo implementato più di un progetto di integrazione con esse. Ma una cosa è implementare un compito specifico per un cliente, formare il personale e, magari, acquistare il supporto di un grande fornitore, e un'altra cosa è creare un prodotto facilmente replicabile che verrà utilizzato per vari compiti, cosa che noi, come venditore, potremmo anche sapere di noi stessi, non lo faremo. Per il secondo scopo, i prodotti open source esistenti non erano adatti a noi, quindi abbiamo deciso di creare noi stessi un file system distribuito.
Due anni dopo, diversi sviluppatori (che hanno combinato il lavoro su vAIR con il lavoro sul classico sistema di archiviazione Engine) hanno ottenuto un certo risultato.
Nel 2018 avevamo scritto un semplice file system e lo abbiamo integrato con l’hardware necessario. Il sistema combinava dischi fisici (locali) di diversi server in un pool flat tramite un'interconnessione interna e li "tagliava" in blocchi virtuali, quindi dai blocchi virtuali venivano creati dispositivi a blocchi con vari gradi di tolleranza agli errori, sui quali venivano creati quelli virtuali. ed eseguito utilizzando le macchine hypervisor KVM.
Non ci siamo preoccupati troppo del nome del file system e lo abbiamo chiamato brevemente ARDFS (indovina cosa significa))
Questo prototipo aveva un bell'aspetto (non visivamente, ovviamente, non esisteva ancora il visual design) e mostrava buoni risultati in termini di prestazioni e scalabilità. Dopo il primo vero risultato, abbiamo avviato questo progetto, organizzando un ambiente di sviluppo completo e un team separato che si occupava solo di vAIR.
Proprio a quel punto era maturata l'architettura generale della soluzione, che non ha ancora subito grandi modifiche.
Immersione nel file system ARDFS
ARDFS è la base di vAIR, che fornisce storage di dati distribuito e con tolleranza agli errori nell'intero cluster. Una delle (ma non l'unica) caratteristica distintiva di ARDFS è che non utilizza server dedicati aggiuntivi per i metadati e la gestione. Questo è stato originariamente concepito per semplificare la configurazione della soluzione e per la sua affidabilità.
Struttura di stoccaggio
All'interno di tutti i nodi del cluster, ARDFS organizza un pool logico da tutto lo spazio su disco disponibile. È importante capire che un pool non è ancora dati o spazio formattato, ma semplicemente markup, ad es. Tutti i nodi con vAIR installato, quando aggiunti al cluster, vengono automaticamente aggiunti al pool ARDFS condiviso e le risorse disco diventano automaticamente condivise nell'intero cluster (e disponibili per la futura archiviazione dei dati). Questo approccio consente di aggiungere e rimuovere nodi al volo senza alcun impatto serio sul sistema già in esecuzione. Quelli. il sistema è molto semplice da scalare “in brick”, aggiungendo o rimuovendo nodi nel cluster se necessario.
I dischi virtuali (oggetti di archiviazione per macchine virtuali) vengono aggiunti al pool ARDFS, creato da blocchi virtuali di 4 megabyte di dimensione. I dischi virtuali archiviano direttamente i dati. Lo schema di tolleranza agli errori viene impostato anche a livello del disco virtuale.
Come avrai già intuito, per la tolleranza agli errori del sottosistema del disco, non utilizziamo il concetto di RAID (array ridondante di dischi indipendenti), ma utilizziamo RAIN (array ridondante di nodi indipendenti). Quelli. La tolleranza agli errori viene misurata, automatizzata e gestita in base ai nodi, non ai dischi. I dischi, ovviamente, sono anche un oggetto di archiviazione, sono, come tutto il resto, monitorati, con essi è possibile eseguire tutte le operazioni standard, incluso l'assemblaggio di un RAID hardware locale, ma il cluster funziona specificamente sui nodi.
In una situazione in cui si desidera realmente il RAID (ad esempio, uno scenario che supporta più errori su piccoli cluster), nulla impedisce di utilizzare controller RAID locali e di creare sopra uno storage esteso e un'architettura RAIN. Questo scenario è abbastanza vivo ed è da noi supportato, quindi ne parleremo in un articolo sugli scenari tipici per l'utilizzo di vAIR.
Schemi di tolleranza agli errori di archiviazione
Possono essere presenti due schemi di tolleranza agli errori per i dischi virtuali in vAIR:
1) Fattore di replica o semplicemente replica: questo metodo di tolleranza agli errori è semplice come un bastone e una corda. La replica sincrona viene eseguita tra i nodi con un fattore pari a 2 (2 copie per cluster) o 3 (3 copie, rispettivamente). RF-2 consente a un disco virtuale di resistere al guasto di un nodo nel cluster, ma "consuma" metà del volume utile e RF-3 resisterà al guasto di 2 nodi nel cluster, ma riserva 2/3 del volume utile volume utile alle sue esigenze. Questo schema è molto simile a RAID-1, ovvero un disco virtuale configurato in RF-2 è resistente al guasto di qualsiasi nodo del cluster. In questo caso, tutto andrà bene con i dati e anche l'I/O non si fermerà. Quando il nodo caduto tornerà in servizio, inizierà il ripristino/sincronizzazione automatica dei dati.
Di seguito sono riportati esempi della distribuzione dei dati RF-2 e RF-3 in modalità normale e in situazione di guasto.
Disponiamo di una macchina virtuale con una capacità di 8 MB di dati univoci (utili), che gira su 4 nodi vAIR. È chiaro che in realtà è improbabile che ci sia un volume così piccolo, ma per uno schema che riflette la logica del funzionamento di ARDFS, questo esempio è il più comprensibile. AB sono blocchi virtuali da 4 MB contenenti dati univoci della macchina virtuale. RF-2 crea rispettivamente due copie di questi blocchi A1+A2 e B1+B2. Questi blocchi sono "disposti" tra i nodi, evitando l'intersezione degli stessi dati sullo stesso nodo, ovvero la copia A1 non si troverà sullo stesso nodo della copia A2. Stessa cosa con B1 e B2.
Se uno dei nodi fallisce (ad esempio, il nodo n. 3, che contiene una copia di B1), questa copia viene automaticamente attivata sul nodo dove non è presente alcuna copia della sua copia (cioè una copia di B2).
Pertanto, il disco virtuale (e di conseguenza la VM) può facilmente sopravvivere al guasto di un nodo nello schema RF-2.
Lo schema di replica, sebbene semplice e affidabile, soffre dello stesso problema di RAID1: spazio utilizzabile insufficiente.
2) La codifica di cancellazione o codifica di cancellazione (nota anche come “codifica ridondante”, “codifica di cancellazione” o “codice di ridondanza”) esiste per risolvere il problema di cui sopra. EC è uno schema di ridondanza che fornisce un'elevata disponibilità dei dati con un sovraccarico di spazio su disco inferiore rispetto alla replica. Il principio di funzionamento di questo meccanismo è simile a RAID 5, 6, 6P.
Durante la codifica, il processo EC divide un blocco virtuale (4 MB per impostazione predefinita) in diversi "pezzi di dati" più piccoli a seconda dello schema EC (ad esempio, uno schema 2+1 divide ciascun blocco da 4 MB in 2 blocchi da 2 MB). Successivamente, questo processo genera “pezzi di parità” per i “pezzi di dati” che non sono più grandi di una delle parti precedentemente divise. Durante la decodifica, EC genera i blocchi mancanti leggendo i dati "sopravvissuti" nell'intero cluster.
Ad esempio, un disco virtuale con uno schema EC 2 + 1, implementato su 4 nodi del cluster, resisterà facilmente al guasto di un nodo del cluster allo stesso modo di RF-2. In questo caso i costi generali saranno inferiori, in particolare il coefficiente di capacità utile per RF-2 sarà 2 e per EC 2+1 sarà 1,5.
Per descriverlo più semplicemente, la sostanza è che il blocco virtuale viene diviso in 2-8 (perché da 2 a 8, vedi sotto) “pezzi”, e per questi pezzi vengono calcolati “pezzi” di parità di volume simile.
Di conseguenza, i dati e la parità vengono distribuiti uniformemente su tutti i nodi del cluster. Allo stesso tempo, come nel caso della replica, ARDFS distribuisce automaticamente i dati tra i nodi in modo tale da impedire che dati identici (copie dei dati e loro parità) vengano archiviati sullo stesso nodo, al fine di eliminare la possibilità di perdere dati a causa al fatto che i dati e la loro parità finiranno improvvisamente su un nodo di archiviazione che fallisce.
Di seguito è riportato un esempio, con la stessa macchina virtuale da 8 MB e 4 nodi, ma con uno schema EC 2+1.
I blocchi A e B sono divisi in due pezzi da 2 MB ciascuno (due perché 2+1), cioè A1+A2 e B1+B2. A differenza di una replica, A1 non è una copia di A2, è un blocco virtuale A, diviso in due parti, lo stesso del blocco B. In totale, otteniamo due set da 4 MB, ciascuno dei quali contiene due pezzi da due MB. Successivamente, per ciascuno di questi set, viene calcolata la parità con un volume non superiore a un pezzo (ovvero 2 MB), otteniamo ulteriori + 2 pezzi di parità (AP e BP). In totale abbiamo dati 4×2 + parità 2×2.
Successivamente, i pezzi vengono “disposti” tra i nodi in modo che i dati non si intersechino con la loro parità. Quelli. A1 e A2 non si troveranno sullo stesso nodo di AP.
In caso di guasto di un nodo (ad esempio, anche il terzo), il blocco B1 caduto verrà automaticamente ripristinato dalla parità BP, che è memorizzata sul nodo n. 2, e verrà attivato sul nodo dove è presente nessuna parità B, cioè pezzo di BP. In questo esempio, questo è il nodo n. 1
Sono sicuro che il lettore abbia una domanda:
"Tutto ciò che hai descritto è stato a lungo implementato sia dai concorrenti che in soluzioni open source, qual è la differenza tra la tua implementazione di EC in ARDFS?"
E poi ci saranno funzionalità interessanti di ARDFS.
Codifica di cancellazione con particolare attenzione alla flessibilità
Inizialmente, abbiamo fornito uno schema EC X+Y abbastanza flessibile, dove X è uguale a un numero da 2 a 8 e Y è uguale a un numero da 1 a 8, ma sempre minore o uguale a X. Questo schema è fornito per la flessibilità. Aumentare il numero di dati (X) in cui è suddiviso il blocco virtuale consente di ridurre i costi generali, ovvero di aumentare lo spazio utilizzabile.
Aumentando il numero di blocchi di parità (Y) aumenta l'affidabilità del disco virtuale. Maggiore è il valore Y, maggiore è il numero di nodi nel cluster che possono guastarsi. Naturalmente, l’aumento del volume di parità riduce la quantità di capacità utilizzabile, ma questo è un prezzo da pagare per l’affidabilità.
La dipendenza delle prestazioni dai circuiti EC è quasi diretta: più “pezzi”, minore è la prestazione; qui, ovviamente, è necessaria una visione equilibrata.
Questo approccio consente agli amministratori di configurare lo storage esteso con la massima flessibilità. All'interno del pool ARDFS è possibile utilizzare qualsiasi schema di tolleranza agli errori e le loro combinazioni, il che, a nostro avviso, è anche molto utile.
Di seguito è riportata una tabella che confronta diversi (non tutti possibili) schemi RF ed EC.
Dalla tabella si vede che anche la combinazione più “terry” EC 8+7, che permette la perdita simultanea di fino a 7 nodi in un cluster, “consuma” meno spazio utilizzabile (1,875 contro 2) rispetto alla replica standard, e protegge 7 volte meglio , il che rende questo meccanismo di protezione, sebbene più complesso, molto più attraente nelle situazioni in cui è necessario garantire la massima affidabilità in condizioni di spazio su disco limitato. Allo stesso tempo, devi capire che ogni "più" su X o Y costituirà un ulteriore sovraccarico in termini di prestazioni, quindi nel triangolo tra affidabilità, risparmio e prestazioni devi scegliere con molta attenzione. Per questo motivo dedicheremo un articolo a parte al dimensionamento della codifica di cancellazione.
Affidabilità e autonomia del file system
ARDFS funziona localmente su tutti i nodi del cluster e li sincronizza con mezzi propri attraverso interfacce Ethernet dedicate. Il punto importante è che ARDFS sincronizza in modo indipendente non solo i dati, ma anche i metadati relativi allo storage. Mentre lavoravamo su ARDFS, abbiamo studiato contemporaneamente una serie di soluzioni esistenti e abbiamo scoperto che molte sincronizzano il meta del file system utilizzando un DBMS distribuito esterno, che utilizziamo anche per la sincronizzazione, ma solo le configurazioni, non i metadati FS (su questo e altri sottosistemi correlati nel prossimo articolo).
La sincronizzazione dei metadati FS utilizzando un DBMS esterno è, ovviamente, una soluzione funzionante, ma la consistenza dei dati archiviati su ARDFS dipenderebbe dal DBMS esterno e dal suo comportamento (e, francamente, è una donna capricciosa), che in la nostra opinione è negativa. Perché? Se i metadati FS vengono danneggiati, anche i dati FS stessi possono essere salutati, quindi abbiamo deciso di intraprendere un percorso più complesso ma affidabile.
Abbiamo realizzato noi stessi il sottosistema di sincronizzazione dei metadati per ARDFS e funziona in modo completamente indipendente dai sottosistemi adiacenti. Quelli. nessun altro sottosistema può corrompere i dati ARDFS. A nostro avviso questo è il modo più affidabile e corretto, ma il tempo dirà se è effettivamente così. Inoltre, questo approccio presenta un ulteriore vantaggio. ARDFS può essere utilizzato indipendentemente da vAIR, proprio come lo stretched storage, che utilizzeremo sicuramente nei prodotti futuri.
Di conseguenza, sviluppando ARDFS, abbiamo ottenuto un file system flessibile e affidabile che offre la possibilità di scegliere se risparmiare sulla capacità o rinunciare a tutto sulle prestazioni o realizzare uno storage ultra affidabile a un costo ragionevole, ma riducendo i requisiti di prestazioni.
Insieme a una politica di licenza semplice e a un modello di distribuzione flessibile (guardando al futuro, vAIR viene concesso in licenza per nodo e fornito come software o come pacchetto software), ciò consente di adattare in modo molto preciso la soluzione a un'ampia varietà di requisiti e esigenze dei clienti. quindi mantenere facilmente questo equilibrio.
Chi ha bisogno di questo miracolo?
Da un lato possiamo dire che sul mercato esistono già operatori che offrono soluzioni serie nel campo dell’iperconvergenza, ed è proprio qui che ci stiamo dirigendo. Sembra che questa affermazione sia vera, MA...
Quando invece andiamo nei campi e comunichiamo con i clienti, noi e i nostri partner vediamo che non è affatto così. Ci sono molti compiti per l’iperconvergenza, in alcuni luoghi le persone semplicemente non sapevano che tali soluzioni esistessero, in altri sembravano costose, in altri ci sono stati test infruttuosi di soluzioni alternative, e in altri addirittura vietano l’acquisto a causa delle sanzioni. In generale, il campo si è rivelato non arato, quindi siamo andati a sollevare il terreno vergine))).
Quando il sistema di archiviazione è migliore di GCS?
Lavorando con il mercato, spesso ci viene chiesto quando è meglio utilizzare uno schema classico con sistemi di accumulo e quando utilizzare l'iperconvergente? Molte aziende produttrici di GCS (soprattutto quelle che non hanno sistemi di storage nel proprio portafoglio) affermano: “I sistemi di storage stanno diventando obsoleti, solo iperconvergenti!” Questa è un’affermazione audace, ma non riflette interamente la realtà.
In verità, il mercato dello storage si sta muovendo verso l’iperconvergenza e soluzioni simili, ma c’è sempre un “ma”.
In primo luogo, i data center e le infrastrutture IT costruiti secondo lo schema classico con sistemi di storage non possono essere facilmente ricostruiti, quindi la modernizzazione e il completamento di tali infrastrutture è ancora un'eredità per 5-7 anni.
In secondo luogo, la maggior parte dell'infrastruttura attualmente in costruzione (ovvero la Federazione Russa) è costruita secondo lo schema classico utilizzando sistemi di storage, e non perché le persone non conoscano l'iperconvergenza, ma perché il mercato dell'iperconvergenza è nuovo, soluzioni e gli standard non sono ancora stati stabiliti, il personale IT non è ancora formato, ha poca esperienza, ma deve costruire data center qui e ora. E questa tendenza durerà per altri 3-5 anni (e poi un’altra eredità, vedi punto 1).
In terzo luogo, esiste una limitazione puramente tecnica in ulteriori piccoli ritardi di 2 millisecondi per scrittura (esclusa la cache locale, ovviamente), che rappresentano il costo dello storage distribuito.
Bene, non dimentichiamoci dell'uso di server fisici di grandi dimensioni che amano il ridimensionamento verticale del sottosistema del disco.
Esistono molte attività necessarie e popolari in cui i sistemi di storage si comportano meglio di GCS. Qui, ovviamente, quei produttori che non hanno sistemi di accumulo nel loro portafoglio di prodotti non saranno d'accordo con noi, ma siamo pronti a discutere in modo ragionevole. Naturalmente, come sviluppatori di entrambi i prodotti, confronteremo sicuramente i sistemi di storage e GCS in una delle nostre future pubblicazioni, dove dimostreremo chiaramente quale è meglio in quali condizioni.
E dove le soluzioni iperconvergenti funzioneranno meglio dei sistemi di storage?
Sulla base di quanto sopra si possono trarre tre ovvie conclusioni:
- Laddove ulteriori 2 millisecondi di latenza per la registrazione, che si verificano costantemente in qualsiasi prodotto (ora non stiamo parlando di sintetici, i nanosecondi possono essere mostrati su sintetici), sono acritici, è adatto l'iperconvergente.
- Laddove il carico di grandi server fisici può essere trasformato in tanti piccoli server virtuali e distribuito tra i nodi, anche lì l’iperconvergenza funzionerà bene.
- Laddove il ridimensionamento orizzontale ha una priorità più alta rispetto al ridimensionamento verticale, GCS andrà benissimo anche lì.
Quali sono queste soluzioni?
- Tutti i servizi di infrastruttura standard (servizio di directory, posta, EDMS, file server, sistemi ERP e BI di piccole o medie dimensioni, ecc.). Chiamiamo questo “informatica generale”.
- L'infrastruttura dei fornitori di servizi cloud, dove è necessario espandere orizzontalmente in modo rapido e standardizzato e “tagliare” facilmente un gran numero di macchine virtuali per i clienti.
- Infrastruttura desktop virtuale (VDI), in cui molte macchine virtuali di piccoli utenti vengono eseguite e "fluttuano" silenziosamente all'interno di un cluster uniforme.
- Reti di filiali, in cui ciascuna filiale necessita di un'infrastruttura standard, con tolleranza ai guasti ma economica di 15-20 macchine virtuali.
- Qualsiasi elaborazione distribuita (servizi di big data, ad esempio). Dove il carico non va “in profondità”, ma “in larghezza”.
- Ambienti di test in cui sono accettabili ulteriori piccoli ritardi, ma ci sono restrizioni di budget, perché si tratta di test.
Al momento, è per questi compiti che abbiamo creato AERODISK vAIR ed è su questi che ci stiamo concentrando (finora con successo). Forse questo cambierà presto, perché... il mondo non si ferma.
Quindi ...
Si completa così la prima parte di una nutrita serie di articoli; nel prossimo articolo parleremo dell'architettura della soluzione e dei componenti utilizzati.
Diamo il benvenuto a domande, suggerimenti e controversie costruttive.
Fonte: habr.com