Salutare, cititori Habr. Cu acest articol deschidem o serie care va vorbi despre sistemul hiperconvergent AERODISK vAIR pe care l-am dezvoltat. Inițial, am vrut să spunem totul despre totul în primul articol, dar sistemul este destul de complex, așa că vom mânca elefantul pe părți.
Să începem povestea cu istoria creării sistemului, să pătrundem în sistemul de fișiere ARDFS, care stă la baza vAIR și să vorbim puțin despre poziționarea acestei soluții pe piața rusă.
În articolele viitoare vom vorbi mai detaliat despre diferitele componente arhitecturale (cluster, hypervisor, echilibrator de încărcare, sistem de monitorizare etc.), despre procesul de configurare, vom ridica probleme de licențiere, vom arăta separat testele de blocare și, bineînțeles, vom scrie despre testarea încărcării și dimensionarea. De asemenea, vom dedica un articol separat versiunii comunitare a vAIR.
Este Aerodisk o poveste despre sistemele de stocare? Sau de ce am început să facem hiperconvergență în primul rând?
Inițial, ideea de a ne crea propria hiperconvergență ne-a venit undeva în jurul anului 2010. La acea vreme, pe piață nu exista nici Aerodisk, nici soluții similare (sisteme hiperconvergente comerciale în cutie). Sarcina noastră a fost următoarea: dintr-un set de servere cu discuri locale, unite printr-o interconexiune prin protocolul Ethernet, a fost necesar să creăm o stocare extinsă și să lansăm acolo mașini virtuale și o rețea software. Toate acestea trebuiau implementate fără sisteme de stocare (pentru că pur și simplu nu existau bani pentru sistemele de stocare și hardware-ul acestuia și încă nu ne inventasem propriile sisteme de stocare).
Am încercat multe soluții open source și am rezolvat în cele din urmă această problemă, dar soluția a fost foarte complexă și greu de repetat. În plus, această soluție era în categoria „Funcționează? Nu atinge! Prin urmare, după ce am rezolvat această problemă, nu am dezvoltat în continuare ideea de a transforma rezultatul muncii noastre într-un produs cu drepturi depline.
După acel incident, ne-am îndepărtat de această idee, dar încă aveam senzația că această problemă este complet rezolvabilă, iar beneficiile unei astfel de soluții erau mai mult decât evidente. Ulterior, produsele HCI lansate de companii străine au confirmat doar acest sentiment.
Prin urmare, la jumătatea anului 2016, am revenit la această sarcină ca parte a creării unui produs cu drepturi depline. La acea vreme nu aveam încă relații cu investitorii, așa că a trebuit să cumpărăm un stand de dezvoltare pentru banii noștri nu foarte mari. După ce am colectat servere și switch-uri uzate pe Avito, ne-am apucat de treabă.
Sarcina inițială principală a fost să ne creăm propriul sistem de fișiere, deși simplu, dar propriu, care ar putea distribui automat și uniform datele sub formă de blocuri virtuale pe al n-lea număr de noduri de cluster, care sunt conectate printr-o interconexiune prin Ethernet. În același timp, FS ar trebui să se scaleze bine și ușor și să fie independent de sistemele adiacente, de exemplu. să fie înstrăinat de vAIR sub forma „doar o unitate de depozitare”.
Primul concept vAIR
Am renunțat în mod deliberat la utilizarea soluțiilor open source gata făcute pentru organizarea stocării extinse (ceph, gluster, luster și altele asemenea) în favoarea propriei dezvoltări, deoarece aveam deja multă experiență de proiect cu ele. Desigur, aceste soluții în sine sunt excelente și, înainte de a lucra la Aerodisk, am implementat mai mult de un proiect de integrare cu ele. Dar una este să implementezi o sarcină specifică pentru un client, să instruim personalul și, poate, să cumperi sprijinul unui furnizor mare și cu totul altceva să creăm un produs ușor de replicat, care va fi folosit pentru diverse sarcini, pe care noi, în calitate de furnizor, poate chiar știm despre noi înșine, nu vom face. Pentru al doilea scop, produsele open source existente nu erau potrivite pentru noi, așa că am decis să creăm noi înșine un sistem de fișiere distribuit.
Doi ani mai târziu, mai mulți dezvoltatori (care au combinat munca la vAIR cu munca la sistemul clasic de stocare Engine) au obținut un anumit rezultat.
Până în 2018, am scris un sistem de fișiere simplu și l-am completat cu hardware-ul necesar. Sistemul a combinat discuri fizice (locale) de la diferite servere într-un singur pool plat printr-o interconexiune internă și le-a „taiat” în blocuri virtuale, apoi au fost create dispozitive de blocare cu diferite grade de toleranță la erori din blocurile virtuale, pe care au fost create cele virtuale. și executat folosind mașinile cu hypervisor KVM.
Nu ne-am deranjat prea mult cu numele sistemului de fișiere și l-am numit succint ARDFS (ghiciți ce înseamnă))
Acest prototip arăta bine (nu din punct de vedere vizual, desigur, nu a existat încă un design vizual) și a arătat rezultate bune în ceea ce privește performanța și scalarea. După primul rezultat real, am pus acest proiect în mișcare, organizând un mediu de dezvoltare cu drepturi depline și o echipă separată care s-a ocupat doar de vAIR.
Chiar în acel moment, arhitectura generală a soluției se maturizase, care nu a suferit încă modificări majore.
Scufundare în sistemul de fișiere ARDFS
ARDFS este fundamentul vAIR, care oferă stocare de date distribuită, tolerantă la erori în întregul cluster. Una dintre (dar nu singurele) caracteristici distinctive ale ARDFS este că nu utilizează niciun server dedicat suplimentar pentru metadate și management. Acesta a fost conceput inițial pentru a simplifica configurația soluției și pentru fiabilitatea acesteia.
Structura de depozitare
În toate nodurile clusterului, ARDFS organizează un pool logic din tot spațiul disponibil pe disc. Este important să înțelegeți că un pool nu este încă date sau spațiu formatat, ci pur și simplu marcaj, de exemplu. Orice noduri cu vAIR instalat, atunci când sunt adăugate la cluster, sunt adăugate automat la pool-ul ARDFS partajat, iar resursele de disc devin automat partajate în întregul cluster (și disponibile pentru stocarea viitoare a datelor). Această abordare vă permite să adăugați și să eliminați noduri din mers fără niciun impact serios asupra sistemului care rulează deja. Acestea. Sistemul este foarte ușor de scalat „în cărămizi”, adăugând sau eliminând noduri din cluster, dacă este necesar.
Discurile virtuale (obiecte de stocare pentru mașinile virtuale) sunt adăugate peste pool-ul ARDFS, care sunt construite din blocuri virtuale de 4 megaocteți. Discurile virtuale stochează direct date. Schema de toleranță la erori este setată și la nivel de disc virtual.
După cum probabil ați ghicit deja, pentru toleranța la erori a subsistemului de disc, nu folosim conceptul de RAID (Redundant array of independent Disks), ci folosim RAIN (Redundant array of independent Nodes). Acestea. Toleranța la erori este măsurată, automatizată și gestionată pe baza nodurilor, nu a discurilor. Discurile, desigur, sunt și un obiect de stocare, ele, ca orice altceva, sunt monitorizate, puteți efectua toate operațiunile standard cu ele, inclusiv asamblarea unui RAID hardware local, dar clusterul funcționează în mod specific pe noduri.
Într-o situație în care doriți cu adevărat RAID (de exemplu, un scenariu care acceptă mai multe eșecuri pe clustere mici), nimic nu vă împiedică să utilizați controlere RAID locale și să construiți stocare extinsă și o arhitectură RAIN pe deasupra. Acest scenariu este destul de live și este susținut de noi, așa că vom vorbi despre el într-un articol despre scenariile tipice pentru utilizarea vAIR.
Scheme de toleranță la erori de stocare
Pot exista două scheme de toleranță la erori pentru discurile virtuale în vAIR:
1) Factorul de replicare sau pur și simplu replicare - această metodă de toleranță la greșeală este la fel de simplă ca un băț și o frânghie. Replicarea sincronă se realizează între noduri cu un factor de 2 (2 copii per cluster) sau 3 (respectiv 3 copii). RF-2 permite unui disc virtual să reziste la defecțiunea unui nod din cluster, dar „mâncă” jumătate din volumul util, iar RF-3 va rezista la defecțiunea a 2 noduri din cluster, dar își rezervă 2/3 din volum util pentru nevoile sale. Această schemă este foarte asemănătoare cu RAID-1, adică un disc virtual configurat în RF-2 este rezistent la defecțiunea oricărui nod din cluster. În acest caz, totul va fi bine cu datele și nici măcar I/O nu se va opri. Când nodul căzut revine în funcțiune, va începe recuperarea/sincronizarea automată a datelor.
Mai jos sunt exemple de distribuție a datelor RF-2 și RF-3 în modul normal și într-o situație de defecțiune.
Avem o mașină virtuală cu o capacitate de 8MB de date unice (utile), care rulează pe 4 noduri vAIR. Este clar că, în realitate, este puțin probabil să existe un volum atât de mic, dar pentru o schemă care reflectă logica funcționării ARDFS, acest exemplu este cel mai de înțeles. AB sunt blocuri virtuale de 4 MB care conțin date unice ale mașinii virtuale. RF-2 creează două copii ale acestor blocuri A1+A2 și, respectiv, B1+B2. Aceste blocuri sunt „dispuse” peste noduri, evitând intersecția acelorași date pe același nod, adică copia A1 nu va fi localizată pe același nod ca și copia A2. La fel și cu B1 și B2.
Dacă unul dintre noduri eșuează (de exemplu, nodul nr. 3, care conține o copie a lui B1), această copie este activată automat pe nodul unde nu există o copie a copiei sale (adică o copie a lui B2).
Astfel, discul virtual (și VM, în consecință) poate supraviețui cu ușurință eșecului unui nod în schema RF-2.
Schema de replicare, deși simplă și fiabilă, suferă de aceeași problemă ca RAID1 - spațiu insuficient utilizabil.
2) Codarea de ștergere sau codarea de ștergere (cunoscută și sub denumirea de „codare redundantă”, „codare de ștergere” sau „cod de redundanță”) există pentru a rezolva problema de mai sus. EC este o schemă de redundanță care oferă o disponibilitate ridicată a datelor cu o suprasarcină mai mică de spațiu pe disc în comparație cu replicarea. Principiul de funcționare al acestui mecanism este similar cu RAID 5, 6, 6P.
La codificare, procesul EC împarte un bloc virtual (4MB în mod implicit) în mai multe „bucăți de date” mai mici, în funcție de schema EC (de exemplu, o schemă 2+1 împarte fiecare bloc de 4MB în 2 bucăți de 2MB). Apoi, acest proces generează „bucăți de paritate” pentru „bucățile de date” care nu sunt mai mari decât una dintre părțile divizate anterior. La decodare, EC generează bucățile lipsă citind datele „supraviețuitoare” în întregul cluster.
De exemplu, un disc virtual cu o schemă 2 + 1 EC, implementat pe 4 noduri de cluster, va rezista cu ușurință eșecului unui nod din cluster în același mod ca RF-2. În acest caz, costurile generale vor fi mai mici, în special, coeficientul de capacitate utilă pentru RF-2 este 2, iar pentru EC 2+1 va fi 1,5.
Pentru a o descrie mai simplu, esența este că blocul virtual este împărțit în 2-8 (de ce de la 2 la 8, vezi mai jos) „bucăți”, iar pentru aceste piese se calculează „bucăți” de paritate de un volum similar.
Ca rezultat, datele și paritatea sunt distribuite uniform în toate nodurile clusterului. În același timp, ca și în cazul replicării, ARDFS distribuie automat datele între noduri astfel încât să împiedice stocarea datelor identice (copii ale datelor și paritatea acestora) pe același nod, pentru a elimina șansa pierderii datelor datorate. la faptul că datele și paritatea lor vor ajunge brusc pe un singur nod de stocare care eșuează.
Mai jos este un exemplu, cu aceeași mașină virtuală de 8 MB și 4 noduri, dar cu o schemă EC 2+1.
Blocurile A și B sunt împărțite în două bucăți de câte 2 MB fiecare (două pentru că 2+1), adică A1+A2 și B1+B2. Spre deosebire de o replică, A1 nu este o copie a lui A2, este un bloc virtual A, împărțit în două părți, la fel cu blocul B. În total, obținem două seturi de 4MB, fiecare conținând două bucăți de doi MB. În continuare, pentru fiecare dintre aceste seturi, paritatea este calculată cu un volum de cel mult o bucată (adică 2 MB), obținem un plus + 2 bucăți de paritate (AP și BP). În total avem date 4×2 + paritate 2×2.
Apoi, piesele sunt „aranjate” peste noduri, astfel încât datele să nu se intersecteze cu paritatea lor. Acestea. A1 și A2 nu vor fi pe același nod cu AP.
În cazul unei defecțiuni a unui nod (de exemplu, și al treilea), blocul B1 căzut va fi restabilit automat din paritatea BP, care este stocată pe nodul nr. 2 și va fi activat pe nodul unde există fără paritate B, adică bucată de BP. În acest exemplu, acesta este nodul nr. 1
Sunt sigur că cititorul are o întrebare:
„Tot ceea ce ați descris a fost implementat de mult timp atât de concurenți, cât și în soluții open source, care este diferența dintre implementarea dumneavoastră a EC în ARDFS?”
Și apoi vor exista caracteristici interesante ale ARDFS.
Ștergeți codarea cu accent pe flexibilitate
Inițial, am oferit o schemă EC X+Y destul de flexibilă, unde X este egal cu un număr de la 2 la 8 și Y este egal cu un număr de la 1 la 8, dar întotdeauna mai mic sau egal cu X. Această schemă este furnizată pentru flexibilitate. Creșterea numărului de bucăți de date (X) în care este împărțit blocul virtual permite reducerea costurilor generale, adică creșterea spațiului utilizabil.
Creșterea numărului de bucăți de paritate (Y) crește fiabilitatea discului virtual. Cu cât valoarea Y este mai mare, cu atât mai multe noduri din cluster pot eșua. Desigur, creșterea volumului de paritate reduce cantitatea de capacitate utilizabilă, dar acesta este un preț de plătit pentru fiabilitate.
Dependența performanței de circuitele EC este aproape directă: cu cât mai multe „piese”, cu atât performanța este mai mică; aici, desigur, este nevoie de o viziune echilibrată.
Această abordare permite administratorilor să configureze stocarea extinsă cu flexibilitate maximă. În cadrul pool-ului ARDFS, puteți utiliza orice scheme de toleranță la erori și combinațiile acestora, ceea ce, în opinia noastră, este și foarte util.
Mai jos este un tabel care compară mai multe (nu toate posibile) scheme RF și EC.
Tabelul arată că chiar și cea mai „terry” combinație EC 8+7, care permite pierderea a până la 7 noduri într-un cluster simultan, „mâncă” mai puțin spațiu utilizabil (1,875 față de 2) decât replicarea standard și protejează de 7 ori mai bine , ceea ce face ca acest mecanism de protectie, desi mai complex, mult mai atractiv in situatiile in care este necesar sa se asigure o fiabilitate maxima in conditii de spatiu limitat pe disc. În același timp, trebuie să înțelegeți că fiecare „plus” la X sau Y va reprezenta o performanță suplimentară, așa că în triunghiul dintre fiabilitate, economii și performanță trebuie să alegeți foarte atent. Din acest motiv, vom dedica un articol separat ștergerii dimensionării codurilor.
Fiabilitatea și autonomia sistemului de fișiere
ARDFS rulează local pe toate nodurile clusterului și le sincronizează folosind propriile mijloace prin interfețe Ethernet dedicate. Punctul important este că ARDFS sincronizează în mod independent nu numai datele, ci și metadatele legate de stocare. În timp ce lucram la ARDFS, am studiat simultan o serie de soluții existente și am descoperit că multe sincronizează meta-sistemul de fișiere folosind un DBMS extern distribuit, pe care îl folosim și pentru sincronizare, dar numai configurații, nu metadate FS (despre acesta și alte subsisteme aferente). în articolul următor).
Sincronizarea metadatelor FS folosind un SGBD extern este, desigur, o soluție de lucru, dar apoi consistența datelor stocate pe ARDFS ar depinde de SGBD extern și de comportamentul acestuia (și, sincer vorbind, este o doamnă capricioasă), care în parerea noastra este proasta. De ce? Dacă metadatele FS sunt deteriorate, datele FS în sine pot fi, de asemenea, spuse „la revedere”, așa că am decis să luăm o cale mai complexă, dar mai fiabilă.
Subsistemul de sincronizare a metadatelor l-am creat noi înșine pentru ARDFS și trăiește complet independent de subsistemele adiacente. Acestea. niciun alt subsistem nu poate deteriora datele ARDFS. În opinia noastră, acesta este cel mai fiabil și corect mod, dar timpul ne va spune dacă este de fapt așa. În plus, există un avantaj suplimentar cu această abordare. ARDFS poate fi folosit independent de vAIR, la fel ca și stocarea întinsă, pe care cu siguranță o vom folosi în produsele viitoare.
Drept urmare, prin dezvoltarea ARDFS, am primit un sistem de fișiere flexibil și fiabil, care oferă posibilitatea de a alege în cazul în care puteți economisi capacitate sau puteți renunța la totul la performanță sau puteți face stocare ultra-fiabilă la un cost rezonabil, dar reducând cerințele de performanță.
Împreună cu o politică simplă de licențiere și un model de livrare flexibil (în viitor, vAIR este licențiat pe nod și livrat fie ca software, fie ca pachet software), acest lucru vă permite să adaptați foarte precis soluția la o mare varietate de cerințe ale clienților și apoi menține cu ușurință acest echilibru.
Cine are nevoie de acest miracol?
Pe de o parte, putem spune că există deja jucători pe piață care au soluții serioase în domeniul hiperconvergenței și aici ne îndreptăm de fapt. Se pare că această afirmație este adevărată, DAR...
Pe de altă parte, când ieșim pe câmp și comunicăm cu clienții, noi și partenerii noștri vedem că nu este deloc așa. Există multe sarcini pentru hiperconvergență, în unele locuri oamenii pur și simplu nu știau că există astfel de soluții, în altele părea costisitoare, în altele au existat teste nereușite de soluții alternative, iar în altele interzic deloc cumpărarea din cauza sancțiunilor. În general, câmpul s-a dovedit a fi nearat, așa că ne-am dus să ridicăm pământ virgin))).
Când este sistemul de stocare mai bun decât GCS?
Pe măsură ce lucrăm cu piața, suntem adesea întrebați când este mai bine să folosim o schemă clasică cu sisteme de stocare și când să folosim hiperconvergenta? Multe companii producătoare de GCS (în special cele care nu au sisteme de stocare în portofoliu) spun: „Sistemele de stocare devin învechite, doar hiperconvergente!” Aceasta este o afirmație îndrăzneață, dar nu reflectă în totalitate realitatea.
Într-adevăr, piața de stocare se îndreaptă într-adevăr către hiperconvergență și soluții similare, dar există întotdeauna un „dar”.
În primul rând, centrele de date și infrastructurile IT construite după schema clasică cu sisteme de stocare nu pot fi reconstruite cu ușurință, așa că modernizarea și finalizarea unor astfel de infrastructuri este încă o moștenire de 5-7 ani.
În al doilea rând, infrastructura care se construiește în prezent în cea mai mare parte (adică Federația Rusă) este construită după schema clasică folosind sisteme de stocare și nu pentru că oamenii nu știu despre hiperconvergență, ci pentru că piața hiperconvergenței este nouă, soluții și standardele nu au fost încă stabilite, oamenii IT nu sunt încă instruiți, au puțină experiență, dar trebuie să construiască centre de date aici și acum. Și această tendință va dura încă 3-5 ani (și apoi o altă moștenire, vezi punctul 1).
În al treilea rând, există o limitare pur tehnică în întârzierile mici suplimentare de 2 milisecunde per scriere (excluzând memoria cache locală, desigur), care reprezintă costul stocării distribuite.
Ei bine, să nu uităm de utilizarea serverelor fizice mari care iubesc scalarea verticală a subsistemului de disc.
Există multe sarcini necesare și populare în care sistemele de stocare se comportă mai bine decât GCS. Aici, desigur, acei producători care nu au sisteme de stocare în portofoliul lor de produse nu vor fi de acord cu noi, dar suntem gata să argumentăm în mod rezonabil. Desigur, noi, în calitate de dezvoltatori ai ambelor produse, vom compara cu siguranță sistemele de stocare și GCS într-una dintre publicațiile noastre viitoare, unde vom demonstra clar care este mai bine în ce condiții.
Și unde vor funcționa mai bine soluțiile hiperconvergente decât sistemele de stocare?
Pe baza punctelor de mai sus, se pot trage trei concluzii evidente:
- Acolo unde o latență suplimentară de 2 milisecunde pentru înregistrare, care apare constant în orice produs (acum nu vorbim despre sintetice, nanosecundele pot fi afișate pe sintetice), sunt necritice, hiperconvergenta este potrivită.
- Acolo unde sarcina de la serverele fizice mari poate fi transformată în multe virtuale mici și distribuită între noduri, hiperconvergența va funcționa bine și acolo.
- Acolo unde scalarea orizontală este o prioritate mai mare decât scalarea verticală, GCS se va descurca bine și acolo.
Care sunt aceste solutii?
- Toate serviciile standard de infrastructură (serviciu de director, mail, EDMS, servere de fișiere, sisteme ERP și BI mici sau mijlocii etc.). Numim acest lucru „calculatură generală”.
- Infrastructura furnizorilor de cloud, unde este necesar să se extindă rapid și standardizat pe orizontală și să „taie” cu ușurință un număr mare de mașini virtuale pentru clienți.
- Infrastructura desktop virtuală (VDI), unde multe mașini virtuale mici de utilizatori rulează și „plutesc” în liniște într-un cluster uniform.
- Rețele de filiale, în care fiecare sucursală are nevoie de o infrastructură standard, tolerantă la erori, dar ieftină, de 15-20 de mașini virtuale.
- Orice calcul distribuit (servicii de date mari, de exemplu). Unde sarcina merge nu „în adâncime”, ci „în lățime”.
- Medii de testare în care sunt acceptabile mici întârzieri suplimentare, dar există restricții bugetare, deoarece acestea sunt teste.
În acest moment, pentru aceste sarcini am realizat AERODISK vAIR și tocmai asupra lor ne concentrăm (cu succes până acum). Poate că acest lucru se va schimba în curând, pentru că... lumea nu sta pe loc.
Asa de…
Aceasta completează prima parte a unei mari serii de articole; în articolul următor vom vorbi despre arhitectura soluției și componentele utilizate.
Sunt binevenite întrebări, sugestii și dispute constructive.
Sursa: www.habr.com