Salute, lettori di Habr. Cù stu articulu avemu apertu una seria chì parlerà di u sistema hyperconverged AERODISK vAIR chì avemu sviluppatu. In principiu, avemu vulsutu dì tuttu di tuttu in u primu articulu, ma u sistema hè abbastanza cumplessu, cusì avemu da manghjà l'elefante in parte.
Cuminciamu a storia cù a storia di a creazione di u sistema, sfondate in u sistema di schedari ARDFS, chì hè a basa di vAIR, è ancu parlà un pocu di u pusizzioni di sta suluzione in u mercatu russu.
In articuli futuri, parlemu in più in dettaglio di e diverse cumpunenti architetturali (cluster, hypervisor, load balancer, sistema di monitoraghju, etc.), u prucessu di cunfigurazione, suscitarà prublemi di licenza, mostra separatamente teste di crash è, sicuru, scrive nantu à e teste di carica è dimensionamentu. Dedicaremu ancu un articulu separatu à a versione di a cumunità di vAIR.
Aerodisk hè una storia di sistemi di almacenamiento? O perchè avemu principiatu à fà l'iperconvergenza in u primu locu?
Inizialmente, l'idea di creà a nostra propria iperconvergenza hè ghjunta à noi in qualchì locu intornu à u 2010. À quellu tempu, ùn ci era nè Aerodisk nè suluzioni simili (sistemi iperconvergenti in boxe cummerciale) in u mercatu. U nostru compitu era u seguitu: da un inseme di servitori cù dischi lucali, uniti da una interconnessione via u protokollu Ethernet, era necessariu di creà un almacenamentu allargatu è lancià e macchine virtuali è una rete di software. Tuttu chistu duvia esse implementatu senza sistemi di almacenamentu (perchè ùn ci era solu soldi per i sistemi di almacenamentu è u so hardware, è ùn avemu micca ancu inventatu i nostri sistemi di almacenamentu).
Avemu pruvatu assai suluzioni open source è infine risolviu stu prublema, ma a suluzione era assai cumplessa è difficiuli di ripetiri. Inoltre, sta suluzione era in a categuria di "Funziona? Ùn toccu ! Dunque, dopu avè risoltu stu prublema, ùn avemu micca sviluppatu più l'idea di trasfurmà u risultatu di u nostru travagliu in un pruduttu cumpletu.
Dopu à quellu incidente, avemu alluntanatu da questa idea, ma avemu sempre a sensazione chì stu prublema era solu solubile, è i beneficii di una tale suluzione eranu più ch'è evidenti. In seguitu, i prudutti HCI liberati di cumpagnie straniere anu cunfirmatu solu stu sentimentu.
Per quessa, à a mità di 2016, avemu tornatu à stu compitu cum'è parte di creà un pruduttu cumpletu. À quellu tempu ùn avemu micca avutu ancu alcuna relazione cù l'investituri, cusì avemu avutu à cumprà un stand di sviluppu per i nostri soldi micca assai grande. Dopu avè cullucatu i servitori usati è i switch nantu à Avito, avemu ghjuntu à l'affari.
U compitu iniziale principale era di creà u nostru propiu, ancu sèmplice, ma u nostru sistema di schedari, chì puderia distribuisce automaticamente è equamente e dati in forma di blocchi virtuali nantu à l'nèsimu numaru di nodi di cluster, chì sò cunnessi da una interconnessione via Ethernet. À u listessu tempu, u FS deve scala bè è facilmente è esse indipindenti di i sistemi adiacenti, i.e. esse alienatu da vAIR in forma di "solu una facilità di almacenamento".
U primu cuncettu di vAIR
Avemu deliberatamente abbandunatu l'usu di soluzioni open source pronti per l'urganizazione di l'almacenamiento allungatu (ceph, gluster, luster è simili) in favore di u nostru propiu sviluppu, postu chì avemu digià avutu assai prughjetti di prughjettu cun elli. Di sicuru, sti suluzioni stessi sò eccellenti, è prima di travaglià in Aerodisk, avemu implementatu più di un prughjettu di integrazione cun elli. Ma hè una cosa di implementà un compitu specificu per un cliente, furmà u persunale è, forsi, cumprà u supportu di un grande venditore, è un'altra cosa per creà un pruduttu facilmente replicatu chì serà utilizatu per diverse attività, chì noi, cum'è un venditore, pò ancu sapè di noi stessi ùn avemu micca. Per u sicondu scopu, i prudutti open source esistenti ùn sò micca adattati per noi, cusì avemu decisu di creà un sistema di fugliale distribuitu.
Dui anni dopu, parechji sviluppatori (chì anu cumminatu u travagliu nantu à vAIR cù u travagliu nantu à u sistema classicu di almacenamiento di Engine) hà ottinutu un certu risultatu.
In 2018, avemu avutu scrittu un sistema di fugliale simplice è cumplementatu cù u hardware necessariu. U sistema hà cumminatu i dischi fisici (locali) da diversi servitori in una piscina piatta per via di una interconnessione interna è "tagliate" in blocchi virtuali, dopu bloccà i dispositi cù diversi gradi di tolleranza di difetti sò stati creati da i blocchi virtuali, nantu à quale sò stati creati virtuali. è eseguitu cù i vitture ipervisori KVM.
Ùn avemu micca troppu fastidiu cù u nome di u sistema di fugliale è succintamente chjamatu ARDFS (invintate ciò chì significa))
Stu prototipu pareva bè (micca visualmente, sicuru, ùn ci era ancu un disignu visuale) è hà dimustratu boni risultati in termini di rendiment è scala. Dopu à u primu risultatu veru, avemu messu stu prughjettu in muvimentu, urganizendu un ambiente di sviluppu cumpletu è una squadra separata chì hà trattatu solu cù vAIR.
Giustu à quellu tempu, l'architettura generale di a suluzione era maturata, chì ùn hà micca ancu subitu cambiamenti maiò.
Immergendu in u sistema di fugliale ARDFS
ARDFS hè u fundamentu di vAIR, chì furnisce un almacenamentu di dati distribuitu, tolerante à i difetti in tuttu u cluster. Una di e (ma micca l'unicu) caratteristiche distintive di ARDFS hè chì ùn usa micca servitori addiziunali dedicati per metadata è gestione. Questu hè statu urigginariu cuncipitu per simplificà a cunfigurazione di a suluzione è per a so affidabilità.
Struttura di almacenamiento
In tutti i nodi di u cluster, ARDFS urganizeghja una piscina logica da tuttu u spaziu di discu dispunibule. Hè impurtante à capisce chì una piscina ùn hè ancora dati o spaziu furmatu, ma simpricimenti markup, i.e. Ogni nodu cù vAIR installatu, quandu aghjunghjenu à u cluster, sò automaticamente aghjuntu à u pool ARDFS spartutu è i risorse di discu sò automaticamente spartuti in tuttu u cluster (è dispunibule per u futuru almacenamentu di dati). Stu approcciu vi permette di aghjunghje è sguassate i nodi nantu à a mosca senza alcun impattu seriu nantu à u sistema digià in esecuzione. Quelli. u sistema hè assai faciule di scala "in mattoni", aghjustendu o sguassate nodi in u cluster se ne necessariu.
I dischi virtuali (oggetti di almacenamiento per e macchine virtuali) sò aghjuntu nantu à a piscina ARDFS, chì sò custruiti da blocchi virtuali di 4 megabytes in grandezza. I dischi virtuali immagazzinanu direttamente i dati. U schema di tolleranza di difetti hè ancu stabilitu à u livellu di u discu virtuale.
Cum'è avete digià capitu, per a tolleranza di difetti di u sottosistema di discu, ùn avemu micca usatu u cuncettu di RAID (Matrice Redundante di Dischi Indipendenti), ma aduprà RAIN (Matrice Redundante di Nodi Indipendenti). Quelli. A tolleranza di difetti hè misurata, automatizata è gestita in basa di i nodi, micca di i dischi. I dischi, sicuru, sò ancu un ughjettu di almacenamiento, cum'è tuttu u restu, sò monitorati, pudete fà tutte l'operazioni standard cun elli, cumpresu l'assemblea di un RAID hardware locale, ma u cluster opera specificamente nantu à i nodi.
In una situazione induve vulete veramente RAID (per esempiu, un scenariu chì sustene parechje fallimenti nantu à i picculi clusters), nunda ùn impedisce di utilizà cuntrolli RAID lucali, è custruisce un almacenamentu allungatu è una architettura RAIN in cima. Stu scenariu hè abbastanza vivu è hè sustinutu da noi, cusì ne parlemu in un articulu di scenari tipici per l'usu di vAIR.
Schemi di tolleranza à i difetti di almacenamiento
Ci ponu esse dui schemi di tolleranza di difetti per i dischi virtuali in vAIR:
1) Fattore di replicazione o simpricimenti replicazione - stu metudu di tolleranza di difetti hè simplice quant'è un bastone è una corda. A replicazione sincrona hè realizata trà i nodi cù un fattore di 2 (2 copie per cluster) o 3 (3 copie, rispettivamente). RF-2 permette à un discu virtuale per sustene u fallimentu di un node in u cluster, ma "mange" a mità di u voluminu utile, è RF-3 resisterà à u fallimentu di 2 node in u cluster, ma riserva 2/3 di u cluster. volume utile per i so bisogni. Stu schema hè assai simili à RAID-1, vale à dì, un discu virtuale cunfiguratu in RF-2 hè resistente à u fallimentu di qualsiasi node in u cluster. In questu casu, tuttu sarà bè cù i dati è ancu l'I / O ùn ferma micca. Quandu u node cadutu torna à u serviziu, a ricuperazione automatica di dati / sincronizazione hà da cumincià.
Quì sottu sò esempi di a distribuzione di dati RF-2 è RF-3 in modu normale è in una situazione di fallimentu.
Avemu una macchina virtuale cù una capacità di 8MB di dati unichi (utili), chì corre nantu à 4 nodi vAIR. Hè chjaru chì in a realità hè improbabile chì ci sarà un voluminu cusì chjucu, ma per un schema chì riflette a logica di l'operazione ARDFS, questu esempiu hè u più comprensibile. AB sò blocchi virtuali 4MB chì cuntenenu dati unichi di a macchina virtuale. RF-2 crea duie copie di questi blocchi A1 + A2 è B1 + B2, rispettivamente. Questi blocchi sò "disposti" à traversu i nodi, evitendu l'intersezzione di i stessi dati nantu à u stessu node, vale à dì, a copia A1 ùn serà micca situata nantu à u stessu node cum'è a copia A2. U listessu cù B1 è B2.
Se unu di i nodi falla (per esempiu, u node No. 3, chì cuntene una copia di B1), sta copia hè attivata automaticamente in u node induve ùn ci hè micca copia di a so copia (vale à dì, una copia di B2).
Cusì, u discu virtuale (è u VM, per quessa) ponu facilmente sopravvive à u fallimentu di un node in u schema RF-2.
U schema di replicazione, mentri simplice è affidabile, soffre di u listessu prublema chì RAID1 - micca abbastanza spaziu utilizable.
2) A codificazione di cancellazione o di codificazione di cancellazione (cunnisciutu ancu com'è "codificazione redundante", "codificazione di cancellazione" o "codice di redundancy") esiste per risolve u prublema sopra. EC hè un schema di redundanza chì furnisce una alta dispunibilità di dati cù un spaziu di discu più bassu in quantu à a replicazione. U principiu di funziunamentu di stu mecanismu hè simile à RAID 5, 6, 6P.
Quandu a codificazione, u prucessu EC divide un bloccu virtuale (4MB per difettu) in parechji "pezzi di dati" più chjuchi secondu u schema EC (per esempiu, un schema 2 + 1 divide ogni bloccu 4MB in 2 pezzi 2MB). In seguitu, stu prucessu genera "pezzi di parità" per i "pezzi di dati" chì ùn sò micca più grande di una di e parti precedentemente divise. Quandu decodifica, EC genera i pezzi mancanti leghjendu i dati "sopravviventi" in tuttu u cluster.
Per esempiu, un discu virtuale cù un schema 2 + 1 EC, implementatu nantu à i nodi di cluster 4, resisterà facilmente u fallimentu di un node in u cluster in u listessu modu cum'è RF-2. In questu casu, i costi generali seranu più bassi, in particulare, u coefficient di capacità utile per RF-2 hè 2, è per EC 2 + 1 serà 1,5.
Per discrive più simplicemente, l'essenza hè chì u bloccu virtuale hè divisu in 2-8 (perchè da 2 à 8, vede sottu) "pezzi", è per questi pezzi "pezzi" di parità di un voluminu simili sò calculati.
In u risultatu, i dati è a parità sò distribuiti uniformemente in tutti i nodi di u cluster. À u listessu tempu, cum'è cù a replicazione, ARDFS distribuisce automaticamente e dati trà i nodi in modu chì impedisce chì e dati idèntici (copie di dati è a so parità) sò stati guardati nantu à u stessu nodu, per eliminà a chance di perde dati dovutu. à u fattu chì i dati è a so parità finiscinu di colpu in un node di almacenamiento chì falla.
Quì sottu hè un esempiu, cù a stessa macchina virtuale 8 MB è 4 nodi, ma cù un schema EC 2 + 1.
I blocchi A è B sò divisi in dui pezzi di 2 MB ognunu (dui perchè 2 + 1), vale à dì A1 + A2 è B1 + B2. A diversità di una replica, A1 ùn hè micca una copia di A2, hè un bloccu virtuale A, divisu in dui parti, u listessu cù u bloccu B. In u tutale, avemu dui setti di 4MB, ognunu di i quali cuntene dui pezzi di dui MB. In seguitu, per ognuna di sti setti, a parità hè calculata cù un voluminu di micca più di un pezzu (vale à dì 2 MB), uttene un supplementu + 2 pezzi di parità (AP è BP). In totale avemu 4 × 2 dati + 2 × 2 parità.
In seguitu, i pezzi sò "disposti" trà i nodi per chì e dati ùn si intersectanu cù a so parità. Quelli. A1 è A2 ùn saranu micca nantu à u stessu node cum'è AP.
In l'eventu di un fallimentu di un node (per esempiu, ancu u terzu), u bloccu cadutu B1 serà automaticamente restauratu da a parità BP, chì hè guardatu in u node No 2, è serà attivatu nantu à u node induve ci hè. senza parità B, i.e. un pezzu di BP. In questu esempiu, questu hè u node No 1
Sò sicuru chì u lettore hà una quistione:
"Tuttu ciò chì avete descrittu hè statu longu implementatu sia da i cuncurrenti sia in soluzioni open source, chì hè a diffarenza trà a vostra implementazione di EC in ARDFS?"
E poi ci saranu caratteristiche interessanti di ARDFS.
Sguassà a codificazione cun un focusu nantu à a flessibilità
In principiu, avemu furnitu un schema EC X + Y abbastanza flexible, induve X hè uguali à un numeru da 2 à 8, è Y hè uguale à un numeru da 1 à 8, ma sempre menu o uguale à X. Stu schema hè furnitu. per a flessibilità. Aumentà u nùmeru di pezzi di dati (X) in quale u bloccu virtuale hè divisu permette di riduce i costi di sopra, vale à dì, aumentà u spaziu utilizable.
Aumentà u numeru di pezzi di parità (Y) aumenta l'affidabilità di u discu virtuale. U più grande u valore Y, più nodi in u cluster pò fallu. Di sicuru, l'aumentu di u voluminu di parità reduce a quantità di capacità utilizable, ma questu hè un prezzu per pagà per affidabilità.
A dependenza di e prestazioni nantu à i circuiti EC hè quasi diretta: più "pezzi", u più bassu u rendiment; quì, sicuru, una vista equilibrata hè necessaria.
Stu approcciu permette à l'amministratori di cunfigurà u almacenamentu allungatu cù a massima flessibilità. Dentru a piscina ARDFS, pudete aduprà qualsiasi schema di tolleranza di difetti è e so cumminazzioni, chì, in u nostru parè, hè ancu assai utile.
Quì sottu hè una tavula chì compara parechji (micca tutti pussibuli) schemi RF è EC.
A tavula mostra chì ancu a cumminazzioni più "terry" EC 8 + 7, chì permette a perdita di finu à 7 nodi in un cluster simultaneamente, "manghja" menu spaziu utilizable (1,875 versus 2) cà a replicazione standard, è prutegge 7 volte megliu. , chì face stu mecanismu di prutezzione, ancu s'ellu hè più cumplessu, assai più attraente in situazione induve hè necessariu di assicurà a massima affidabilità in cundizioni di spaziu di discu limitatu. À u listessu tempu, avete bisognu di capiscenu chì ogni "plus" à X o Y serà un soprattuttu di rendiment addiziale, cusì in u triangulu trà affidabilità, risparmiu è rendiment, avete bisognu di sceglie assai cura. Per questu mutivu, avemu da dedicà un articulu separatu per sguassà u sizing di codificazione.
Affidabilità è autonomia di u sistema di schedari
ARDFS funziona in u locu nantu à tutti i nodi di u cluster è li sincronizza cù i so propri mezi attraversu interfacce Ethernet dedicate. U puntu impurtante hè chì ARDFS sincronizza indipindentamente micca solu i dati, ma ancu i metadati ligati à u almacenamiento. Mentre travagliendu in ARDFS, avemu studiatu simultaneamente una quantità di suluzioni esistenti è avemu scupertu chì parechji sincronizzanu a meta di u sistema di schedari utilizendu un DBMS distribuitu esternu, chì avemu ancu aduprà per a sincronizazione, ma solu cunfigurazioni, micca metadata FS (circa questu è altri sottosistemi rilativi). in u prossimu articulu).
Sincronizza metadata FS cù un DBMS esternu hè, sicuru, una suluzione di travagliu, ma allora a coherenza di e dati almacenati in ARDFS dependerà di u DBMS esternu è u so cumpurtamentu (è, francamente, hè una donna capricciosa), chì in a nostra opinione hè male. Perchè? Se i metadati FS si dannu, i dati FS stessu pò ancu esse dettu "addiu", cusì avemu decisu di piglià un percorsu più cumplessu, ma affidabile.
Avemu fattu u subsistema di sincronizazione di metadati per ARDFS noi stessi, è vive in modu completamente indipendente di i sottosistemi adiacenti. Quelli. nisun altru subsistema pò currutti dati ARDFS. In u nostru parè, questu hè u modu più affidabile è currettu, ma u tempu dirà s'ellu hè veramente cusì. Inoltre, ci hè un vantaghju supplementu cù questu approcciu. ARDFS pò esse usatu indipindentamente di vAIR, cum'è l'almacenamiento allungatu, chì certamente useremu in i prudutti futuri.
In u risultatu, sviluppendu ARDFS, avemu ricevutu un sistema di fugliale flessibile è affidabile chì dà una scelta induve pudete salvà a capacità o rinunzià tuttu nantu à u rendiment, o fà un almacenamentu ultra-affidabile à un costu raghjone, ma riducendu i requisiti di rendiment.
Inseme cù una pulitica simplice di licenze è un mudellu di consegna flexible (in u futuru, vAIR hè licenziatu per node, è furnitu sia cum'è software sia cum'è un pacchettu di software), questu permette di adattà assai precisamente a suluzione à una larga varietà di esigenze di i clienti è allora facilmente mantene stu equilibriu.
Quale hè bisognu di stu miraculu ?
Da una banda, pudemu dì chì ci sò digià attori nantu à u mercatu chì anu suluzioni serii in u campu di l'iperconvergenza, è questu hè induve andemu in veru. Sembra chì sta dichjarazione hè vera, MA ...
Per d 'altra banda, quandu andemu in i campi è cumunicà cù i clienti, noi è i nostri partenarii vedemu chì questu ùn hè micca in tuttu u casu. Ci hè parechje travaglii per l'iperconvergenza, in certi lochi a ghjente ùn sapia micca chì tali suluzioni esistenu, in altri pareva caru, in altri ci sò stati testi senza successu di suluzioni alternative, è in altri pruibiscenu cumprà in tuttu per via di sanzioni. In generale, u campu hè diventatu unplowed, cusì andemu à elevà a terra vergine))).
Quandu u sistema di almacenamiento hè megliu cà GKS?
Quandu avemu travagliatu cù u mercatu, avemu spessu dumandatu quandu hè megliu utilizà un schema classicu cù sistemi di almacenamento, è quandu usà iperconvergente? Parechje cumpagnie chì producenu GCS (in particulare quelli chì ùn anu micca sistemi di almacenamentu in a so cartera) dicenu: "I sistemi di almacenamiento sò diventati obsoleti, solu iperconvergii!" Questa hè una dichjarazione audace, ma ùn riflette micca sanu sanu a realità.
In verità, u mercatu di l'almacenamiento si move versu l'iperconvergenza è suluzioni simili, ma ci hè sempre un "ma".
Prima, i centri di dati è l'infrastrutture IT custruite secondu u schema classicu cù sistemi di almacenamento ùn ponu micca esse facilmente ricustruiti, cusì a mudernizazione è a cumpleta di tali infrastrutture hè sempre un legatu per 5-7 anni.
Siconda, l'infrastruttura chì hè attualmente custruita per a maiò parte (chì significheghja a Federazione Russa) hè custruita secondu u schema classicu cù sistemi di almacenamento, è micca perchè a ghjente ùn sapi micca di l'iperconvergenza, ma perchè u mercatu di l'iperconvergenza hè novu, suluzioni è i normi ùn sò micca stati stabiliti, e persone di l'IT ùn sò ancu furmatu, anu poca sperienza, ma anu bisognu di custruisce centri di dati quì è avà. E sta tendenza durà per altri 3-5 anni (è dopu un altru legatu, vede u puntu 1).
In terzu, ci hè una limitazione puramente tecnica in i picculi ritardi supplementari di 2 millisecondi per scrittura (escludendu a cache locale, sicuru), chì sò u costu di almacenamiento distribuitu.
Ebbè, ùn ci scurdemu micca di l'usu di servitori fisichi grandi chì amanu a scala verticale di u sottosistema di discu.
Ci hè parechje travaglii necessarii è populari induve i sistemi di almacenamento si cumportanu megliu cà GCS. Eccu, sicuru, quelli pruduttori chì ùn anu micca sistemi di almacenamento in u so portafoglio di prudutti ùn anu micca d'accordu cun noi, ma simu pronti à argumentà raghjone. Di sicuru, noi, cum'è sviluppatori di i dui prudutti, paragunemu definitivamente i sistemi di almacenamento è GCS in una di e nostre publicazioni future, induve dimustraremu chjaramente quale hè megliu in quali cundizioni.
E induve e soluzioni iperconvergenti funzionanu megliu cà i sistemi di almacenamento?
Basatu nantu à i punti sopra, trè cunclusioni evidenti ponu esse tratte:
- Induve un 2 millisecondi supplementu di latenza per a registrazione, chì si trova sempre in ogni pruduttu (oghje ùn parlemu micca di sintesi, i nanosegundi ponu esse mostrati nantu à i sintetici), ùn sò micca critichi, l'iperconvergenza hè adattata.
- Induve a carica da i servitori fisichi grossi pò esse trasfurmata in parechji picculi virtuali è distribuite trà i nodi, l'iperconvergenza ancu travaglià bè.
- Induve a scala horizontale hè una priorità più altu ch'è a scala verticale, GCS farà ancu bè quì.
Chì sò sti suluzione ?
- Tutti i servizii di l'infrastruttura standard (serviziu di annuariu, mail, EDMS, servitori di file, sistemi ERP è BI chjuchi o medii, etc.). Chjamemu questu "informatica generale".
- L'infrastruttura di i fornitori di nuvola, induve hè necessariu di espansione rapida è standardizata horizontalmente è facilmente "tagliate" un gran numaru di macchine virtuali per i clienti.
- Infrastruttura di desktop virtuale (VDI), induve parechji picculi macchine virtuali d'utilizatori funzionanu è "float" in silenziu in un cluster uniforme.
- Reti di filiale, induve ogni ramu hà bisognu di una infrastruttura standard, tolerante à i difetti, ma pocu costu di 15-20 macchine virtuali.
- Ogni computing distribuitu (servizii di big data, per esempiu). Induve a carica ùn và micca "in prufundità", ma "in larghezza".
- Ambienti di prova induve i picculi ritardi supplementari sò accettabili, ma ci sò restrizioni di bilanciu, perchè sò testi.
À u mumentu, hè per questi travaglii chì avemu fattu AERODISK vAIR è hè nantu à elli chì ci focalizemu (cun successu finu à avà). Forse questu cambierà prestu, perchè ... u mondu ùn si ferma.
Allora…
Questu cumpleta a prima parte di una grande serie di articuli; in u prossimu articulu avemu da parlà di l'architettura di a suluzione è di i cumpunenti utilizati.
Accoltemu dumande, suggerimenti è dispute constructive.
Source: www.habr.com