Pozdrav, čitatelji Habra. Ovim člankom otvaramo seriju koja će govoriti o hiperkonvergentnom sustavu AERODISK vAIR koji smo razvili. U početku smo htjeli reći sve o svemu u prvom članku, ali sustav je prilično složen, pa ćemo slona jesti u dijelovima.
Započnimo priču s poviješću stvaranja sustava, zaronimo u datotečni sustav ARDFS, koji je osnova vAIR-a, a također razgovaramo malo o pozicioniranju ovog rješenja na ruskom tržištu.
U budućim člancima detaljnije ćemo govoriti o različitim arhitektonskim komponentama (klaster, hipervizor, balanser opterećenja, sustav za nadzor itd.), procesu konfiguracije, pokrenuti probleme licenciranja, zasebno prikazati crash testove i, naravno, pisati o testiranju opterećenja i dimenzioniranje. Također ćemo posvetiti poseban članak verziji zajednice vAIR-a.
Je li Aerodisk priča o sustavima za pohranu? Ili zašto smo uopće počeli raditi hiperkonvergenciju?
Inicijalno, ideja o stvaranju vlastite hiperkonvergencije došla nam je negdje oko 2010. godine. U to vrijeme na tržištu nije bilo Aerodiska niti sličnih rješenja (komercijalni boxed hiperkonvergirani sustavi). Naš zadatak je bio sljedeći: od skupa poslužitelja s lokalnim diskovima, objedinjenih interkonekcijom preko Ethernet protokola, trebalo je napraviti proširenu pohranu i tamo pokrenuti virtualne strojeve i softversku mrežu. Sve se to moralo implementirati bez sustava za pohranu (jer jednostavno nije bilo novca za sustave za pohranu i njihov hardver, a mi još nismo izmislili vlastite sustave za pohranu).
Isprobali smo mnoga rješenja otvorenog koda i konačno riješili ovaj problem, ali rješenje je bilo vrlo složeno i teško ponovljivo. Osim toga, ovo je rješenje bilo u kategoriji “Radi li? Ne diraj! Stoga, nakon što smo riješili taj problem, nismo dalje razvijali ideju pretvaranja rezultata našeg rada u punopravni proizvod.
Nakon tog incidenta odmakli smo se od te ideje, ali smo i dalje imali osjećaj da je ovaj problem potpuno rješiv, a dobrobiti ovakvog rješenja više nego očite. Naknadno su objavljeni HCI proizvodi stranih tvrtki samo potvrdili ovaj osjećaj.
Stoga smo se sredinom 2016. vratili ovom zadatku u sklopu stvaranja punopravnog proizvoda. U to vrijeme još nismo imali nikakve odnose s investitorima, pa smo morali kupiti razvojno postolje za vlastiti ne baš veliki novac. Nakon što smo prikupili rabljene servere i sklopke na Avitu, krenuli smo s poslom.
Glavni početni zadatak bio je stvoriti vlastiti, iako jednostavan, ali vlastiti datotečni sustav, koji bi mogao automatski i ravnomjerno distribuirati podatke u obliku virtualnih blokova na n-ti broj čvorova klastera, koji su povezani interkonekcijom preko Etherneta. U isto vrijeme, FS bi se trebao dobro i lako skalirati i biti neovisan o susjednim sustavima, tj. biti otuđen od vAIR-a u obliku “samo skladišta”.
Prvi vAIR koncept
Namjerno smo odustali od korištenja gotovih rješenja otvorenog koda za organiziranje razvučene pohrane (ceph, gluster, luster i slično) u korist vlastitog razvoja, budući da smo s njima već imali dosta projektnog iskustva. Naravno, ova rješenja su sama po sebi izvrsna, a prije rada na Aerodisku s njima smo proveli više od jednog integracijskog projekta. Ali jedna je stvar implementirati specifičan zadatak za jednog kupca, obučiti osoblje i, možda, kupiti podršku velikog dobavljača, a sasvim je druga stvar stvoriti lako repliciran proizvod koji će se koristiti za različite zadatke, koje mi, kao prodavač, možda čak i znati o sebi nećemo. Za drugu namjenu, postojeći proizvodi otvorenog koda nisu bili prikladni za nas, pa smo odlučili sami izraditi distribuirani datotečni sustav.
Dvije godine kasnije, nekoliko programera (koji su kombinirali rad na vAIR-u s radom na klasičnom sustavu za pohranu Enginea) postiglo je određeni rezultat.
Do 2018. napisali smo jednostavan datotečni sustav i nadopunili ga potrebnim hardverom. Sustav je spojio fizičke (lokalne) diskove s različitih poslužitelja u jedan ravni bazen putem interne veze i "izrezao" ih u virtualne blokove, zatim su iz virtualnih blokova kreirani blok uređaji s različitim stupnjevima tolerancije na greške, na kojima su kreirani virtualni i izvršavaju se pomoću automobila KVM hipervizora.
Nismo se previše zamarali nazivom datotečnog sustava i jezgrovito smo ga nazvali ARDFS (pogodite što to znači))
Ovaj prototip je izgledao dobro (naravno, ne vizualno, još nije bilo vizualnog dizajna) i pokazao je dobre rezultate u pogledu performansi i skaliranja. Nakon prvog pravog rezultata, pokrenuli smo ovaj projekt, organizirajući punopravno razvojno okruženje i poseban tim koji se bavio samo vAIR-om.
Upravo je do tada sazrela opća arhitektura rješenja, koja još nije doživjela velike promjene.
Zaronite u ARDFS datotečni sustav
ARDFS je temelj vAIR-a, koji pruža distribuiranu pohranu podataka otpornu na greške u cijelom klasteru. Jedna od (ali ne i jedina) značajka ARDFS-a je da ne koristi nikakve dodatne namjenske poslužitelje za metapodatke i upravljanje. Ovo je izvorno zamišljeno kako bi se pojednostavila konfiguracija rješenja i radi njegove pouzdanosti.
Struktura skladišta
Unutar svih čvorova klastera, ARDFS organizira logički skup od sveg dostupnog diskovnog prostora. Važno je razumjeti da skup još nije podatak ili formatirani prostor, već jednostavno označavanje, tj. Svi čvorovi s instaliranim vAIR-om, kada se dodaju u klaster, automatski se dodaju u zajednički ARDFS skup i resursi diska automatski postaju dijeljeni preko cijelog klastera (i dostupni za buduću pohranu podataka). Ovaj vam pristup omogućuje dodavanje i uklanjanje čvorova u hodu bez ozbiljnog utjecaja na već pokrenuti sustav. Oni. sustav je vrlo lako skalirati "u blokovima", dodajući ili uklanjajući čvorove u klasteru ako je potrebno.
Virtualni diskovi (objekti za pohranu virtualnih strojeva) dodaju se na vrh ARDFS poola, koji su izgrađeni od virtualnih blokova veličine 4 megabajta. Virtualni diskovi izravno pohranjuju podatke. Shema tolerancije grešaka također je postavljena na razini virtualnog diska.
Kao što ste već mogli pogoditi, za toleranciju grešaka diskovnog podsustava ne koristimo koncept RAID (Redundant array ofdependent Disks), već koristimo RAIN (Redundant array ofdependent Nodes). Oni. Tolerancija grešaka se mjeri, automatizira i upravlja na temelju čvorova, a ne diskova. Diskovi su, naravno, također objekt za pohranu, oni se, kao i sve ostalo, nadziru, s njima možete obavljati sve standardne operacije, uključujući sastavljanje lokalnog hardverskog RAID-a, ali klaster radi specifično na čvorovima.
U situaciji u kojoj stvarno želite RAID (na primjer, scenarij koji podržava višestruke kvarove na malim klasterima), ništa vas ne sprječava da koristite lokalne RAID kontrolere i izgradite rastegnutu pohranu i RAIN arhitekturu na vrhu. Ovaj scenarij je prilično aktivan i mi ga podržavamo, pa ćemo o njemu govoriti u članku o tipičnim scenarijima za korištenje vAIR-a.
Sheme tolerancije grešaka u pohrani
Mogu postojati dvije sheme tolerancije grešaka za virtualne diskove u vAIR-u:
1) Faktor replikacije ili jednostavno replikacija - ova metoda tolerancije grešaka jednostavna je poput štapa i užeta. Sinkrona replikacija se izvodi između čvorova s faktorom 2 (2 kopije po klasteru) ili 3 (3 kopije, respektivno). RF-2 omogućuje virtualnom disku da izdrži kvar jednog čvora u klasteru, ali "pojede" polovicu korisnog volumena, a RF-3 će izdržati kvar 2 čvora u klasteru, ali rezervira 2/3 korisni volumen za svoje potrebe. Ova je shema vrlo slična RAID-1, to jest, virtualni disk konfiguriran u RF-2 otporan je na kvar bilo kojeg čvora u klasteru. U ovom slučaju, sve će biti u redu s podacima, pa čak ni I/O neće stati. Kada se pokvareni čvor vrati u funkciju, počet će automatski oporavak/sinkronizacija podataka.
Ispod su primjeri distribucije RF-2 i RF-3 podataka u normalnom načinu rada iu situaciji kvara.
Imamo virtualni stroj s kapacitetom od 8 MB jedinstvenih (korisnih) podataka, koji radi na 4 vAIR čvora. Jasno je da je u stvarnosti malo vjerojatno da će postojati tako mali volumen, ali za shemu koja odražava logiku rada ARDFS-a ovaj je primjer najrazumljiviji. AB su virtualni blokovi od 4 MB koji sadrže jedinstvene podatke virtualnog stroja. RF-2 stvara dvije kopije ovih blokova A1+A2 odnosno B1+B2. Ovi blokovi su "postavljeni" preko čvorova, izbjegavajući križanje istih podataka na istom čvoru, to jest, kopija A1 neće biti smještena na istom čvoru kao kopija A2. Isto s B1 i B2.
Ako jedan od čvorova zakaže (primjerice, čvor br. 3, koji sadrži kopiju B1), ta se kopija automatski aktivira na čvoru na kojem nema kopije njegove kopije (odnosno kopije B2).
Dakle, virtualni disk (i VM, u skladu s tim) može lako preživjeti kvar jednog čvora u RF-2 shemi.
Shema replikacije, iako je jednostavna i pouzdana, pati od istog problema kao i RAID1 - nedovoljno korisnog prostora.
2) Kodiranje za brisanje ili kodiranje za brisanje (također poznato kao "redundantno kodiranje", "kodiranje za brisanje" ili "redundantni kod") postoji za rješavanje gore navedenog problema. EC je redundantna shema koja pruža visoku dostupnost podataka s manjim opterećenjem prostora na disku u usporedbi s replikacijom. Princip rada ovog mehanizma sličan je RAID 5, 6, 6P.
Prilikom kodiranja, EC proces dijeli virtualni blok (4 MB prema zadanim postavkama) u nekoliko manjih "dijelova podataka" ovisno o EC shemi (na primjer, shema 2+1 dijeli svaki blok od 4 MB u 2 bloka od 2 MB). Zatim, ovaj proces generira "paritetne dijelove" za "podatkovne dijelove" koji nisu veći od jednog od prethodno podijeljenih dijelova. Prilikom dekodiranja, EC generira dijelove koji nedostaju čitajući "preživjele" podatke u cijelom klasteru.
Na primjer, virtualni disk sa shemom 2 + 1 EC, implementiran na 4 čvora klastera, lako će izdržati kvar jednog čvora u klasteru na isti način kao RF-2. U tom će slučaju režijski troškovi biti niži, konkretno koeficijent korisnog kapaciteta za RF-2 je 2, a za EC 2+1 1,5.
Jednostavnije rečeno, bit je da se virtualni blok podijeli na 2-8 (zašto od 2 do 8, vidi dolje) “komada”, a za te se komade izračunavaju “komadi” pariteta sličnog volumena.
Kao rezultat toga, podaci i paritet ravnomjerno su raspoređeni po svim čvorovima klastera. Istodobno, kao i kod replikacije, ARDFS automatski distribuira podatke među čvorovima na način da spriječi pohranjivanje identičnih podataka (kopije podataka i njihov paritet) na istom čvoru, kako bi se eliminirala mogućnost gubitka podataka zbog na činjenicu da će podaci i njihov paritet odjednom završiti na jednom čvoru za pohranu koji zakaže.
Ispod je primjer s istim virtualnim strojem od 8 MB i 4 čvora, ali s EC 2+1 shemom.
Blokovi A i B podijeljeni su na dva dijela od po 2 MB (dva jer 2+1), odnosno A1+A2 i B1+B2. Za razliku od replike, A1 nije kopija A2, to je virtualni blok A, podijeljen na dva dijela, isto kao i blok B. Ukupno dobijemo dva seta od 4 MB, od kojih svaki sadrži dva komada od dva MB. Dalje, za svaki od ovih skupova izračunava se paritet s volumenom ne većim od jednog komada (tj. 2 MB), dobivamo dodatna + 2 komada pariteta (AP i BP). Ukupno imamo 4×2 podataka + 2×2 paritet.
Zatim se dijelovi "polažu" između čvorova tako da se podaci ne križaju s njihovim paritetom. Oni. A1 i A2 neće biti na istom čvoru kao AP.
U slučaju kvara jednog čvora (npr. i trećeg), pali blok B1 automatski će se vratiti iz BP pariteta koji je pohranjen na čvoru br. 2, a aktivirat će se na čvoru gdje postoji nema B-pariteta, tj. komad BP. U ovom primjeru, ovo je čvor br. 1
Siguran sam da čitatelj ima pitanje:
"Sve što ste opisali odavno su implementirali i konkurenti i rješenja otvorenog koda, koja je razlika između vaše implementacije EC-a u ARDFS-u?"
A onda će biti zanimljivih značajki ARDFS-a.
Kodiranje za brisanje s fokusom na fleksibilnost
U početku smo pružili prilično fleksibilnu shemu EC X+Y, gdje je X jednako broju od 2 do 8, a Y jednako broju od 1 do 8, ali uvijek manje od ili jednako X. Ova shema je osigurana za fleksibilnost. Povećanje broja dijelova podataka (X) na koje je virtualni blok podijeljen omogućuje smanjenje režijskih troškova, odnosno povećanje korisnog prostora.
Povećanje broja paritetnih dijelova (Y) povećava pouzdanost virtualnog diska. Što je veća vrijednost Y, više čvorova u klasteru može pokvariti. Naravno, povećanje volumena pariteta smanjuje količinu iskoristivog kapaciteta, ali to je cijena koju treba platiti za pouzdanost.
Ovisnost performansi o EC krugovima je gotovo izravna: što je više "komada", to je niža izvedba; ovdje je, naravno, potreban uravnotežen pogled.
Ovaj pristup omogućuje administratorima da konfiguriraju rastegnutu pohranu uz maksimalnu fleksibilnost. Unutar ARDFS skupa možete koristiti bilo koje sheme tolerancije grešaka i njihove kombinacije, što je, po našem mišljenju, također vrlo korisno.
Dolje je tablica koja uspoređuje nekoliko (ne sve moguće) RF i EC shema.
Tablica pokazuje da čak i naj„frotirska“ kombinacija EC 8+7, koja omogućuje gubitak do 7 čvorova u klasteru istovremeno, „jede“ manje korisnog prostora (1,875 naspram 2) od standardne replikacije, a štiti 7 puta bolje , što ovaj mehanizam zaštite, iako složeniji, čini puno atraktivnijim u situacijama kada je potrebno osigurati maksimalnu pouzdanost u uvjetima ograničenog prostora na disku. U isto vrijeme, morate razumjeti da će svaki "plus" na X ili Y biti dodatni troškovi performansi, tako da u trokutu između pouzdanosti, uštede i performansi morate birati vrlo pažljivo. Zbog toga ćemo dimenzioniranju brisanja kodiranja posvetiti poseban članak.
Pouzdanost i autonomija datotečnog sustava
ARDFS radi lokalno na svim čvorovima klastera i sinkronizira ih vlastitim sredstvima putem namjenskih Ethernet sučelja. Važna je točka da ARDFS neovisno sinkronizira ne samo podatke, već i metapodatke koji se odnose na pohranu. Dok smo radili na ARDFS-u, istovremeno smo proučavali niz postojećih rješenja i otkrili smo da mnoga sinkroniziraju meta datotečnog sustava pomoću vanjskog distribuiranog DBMS-a, koji također koristimo za sinkronizaciju, ali samo konfiguracije, ne FS metapodatke (o ovom i drugim povezanim podsustavima u sljedećem članku).
Sinkronizacija FS metapodataka pomoću vanjskog DBMS-a je, naravno, radno rješenje, ali tada bi konzistentnost podataka pohranjenih na ARDFS-u ovisila o vanjskom DBMS-u i njegovom ponašanju (i, iskreno govoreći, to je hirovita dama), što u naše mišljenje je loše. Zašto? Ako se metapodaci FS-a oštete, sami podaci FS-a također se mogu reći "zbogom", pa smo odlučili krenuti složenijim, ali pouzdanijim putem.
Podsustav za sinkronizaciju metapodataka za ARDFS napravili smo sami i on živi potpuno neovisno o susjednim podsustavima. Oni. nijedan drugi podsustav ne može pokvariti ARDFS podatke. Po našem mišljenju, ovo je najpouzdaniji i najispravniji način, ali vrijeme će pokazati je li to stvarno tako. Osim toga, ovaj pristup ima dodatnu prednost. ARDFS se može koristiti neovisno o vAIR-u, baš kao rastegnuta pohrana, koju ćemo sigurno koristiti u budućim proizvodima.
Kao rezultat toga, razvojem ARDFS-a dobili smo fleksibilan i pouzdan datotečni sustav koji daje izbor gdje možete uštedjeti na kapacitetu ili odustati od performansi, ili napraviti ultra-pouzdanu pohranu po razumnoj cijeni, ali smanjujući zahtjeve za performansama.
Zajedno s jednostavnom politikom licenciranja i fleksibilnim modelom isporuke (gledajući unaprijed, vAIR je licenciran po čvoru i isporučuje se ili kao softver ili kao softverski paket), to vam omogućuje da vrlo precizno prilagodite rješenje širokom spektru zahtjeva kupaca i zatim lako održavajte ovu ravnotežu.
Kome treba ovo čudo?
S jedne strane, možemo reći da na tržištu već postoje igrači koji imaju ozbiljna rješenja na području hiperkonvergencije, a tu zapravo i idemo. Čini se da je ova izjava točna, ALI...
S druge strane, kada izađemo na teren i komuniciramo s kupcima, mi i naši partneri vidimo da to uopće nije tako. Mnogo je zadataka za hiperkonvergenciju, negdje ljudi jednostavno nisu znali da takva rješenja postoje, drugdje se to činilo skupim, trećima su bila neuspješna testiranja alternativnih rješenja, a negdje zbog sankcija uopće zabranjuju kupnju. Općenito, pokazalo se da je polje neobrađeno, pa smo otišli podići djevičansko tlo))).
Kada je sustav skladištenja bolji od GKS-a?
Kako radimo s tržištem, često nas pitaju kada je bolje koristiti klasičnu shemu sa sustavima za pohranu, a kada hiperkonvergentnu? Mnoge tvrtke koje proizvode GCS (posebno one koje nemaju sustave za pohranu podataka u svom portfelju) kažu: "Sustavi za pohranu podataka postaju zastarjeli, samo hiperkonvergentni!" Ovo je hrabra izjava, ali ne odražava u potpunosti stvarnost.
Istina, tržište pohrane doista ide prema hiperkonvergenciji i sličnim rješenjima, ali uvijek postoji "ali".
Prvo, podatkovni centri i IT infrastrukture izgrađeni prema klasičnoj shemi sa sustavima za pohranu podataka ne mogu se lako obnoviti, pa je modernizacija i dovršetak takvih infrastruktura još uvijek nasljeđe za 5-7 godina.
Drugo, infrastruktura koja se trenutno gradi najvećim dijelom (misli se na Rusku Federaciju) izgrađena je prema klasičnoj shemi korištenjem sustava za pohranu, i to ne zato što ljudi ne znaju za hiperkonvergenciju, već zato što je tržište hiperkonvergencije novo, rješenja i standardi još nisu uspostavljeni, IT ljudi još nisu obučeni, imaju malo iskustva, ali trebaju graditi podatkovne centre ovdje i sada. I ovaj trend će trajati još 3-5 godina (a onda još jedno nasljeđe, vidi točku 1).
Treće, postoji čisto tehničko ograničenje u dodatnim malim odgodama od 2 milisekunde po pisanju (isključujući lokalnu predmemoriju, naravno), što je trošak distribuirane pohrane.
Pa, nemojmo zaboraviti na korištenje velikih fizičkih poslužitelja koji vole okomito skaliranje diskovnog podsustava.
Postoje mnogi potrebni i popularni zadaci u kojima se sustavi za pohranu ponašaju bolje od GCS-a. Ovdje se, naravno, neće složiti s nama oni proizvođači koji nemaju sustave za pohranu u svom portfelju proizvoda, ali smo spremni argumentirano raspravljati. Naravno, mi, kao programeri oba proizvoda, svakako ćemo usporediti sustave za pohranu i GCS u jednoj od naših budućih publikacija, gdje ćemo jasno pokazati koji je bolji pod kojim uvjetima.
A gdje će hiperkonvergirana rješenja raditi bolje od sustava za pohranu podataka?
Na temelju gore navedenih točaka mogu se izvući tri očita zaključka:
- Tamo gdje su dodatne 2 milisekunde kašnjenja za snimanje, koje se stalno pojavljuju u bilo kojem proizvodu (sada ne govorimo o sintetici, nanosekunde se mogu prikazati na sintetici), prikladne su hiperkonvergentne.
- Tamo gdje se opterećenje s velikih fizičkih poslužitelja može pretvoriti u mnogo malih virtualnih i rasporediti među čvorovima, hiperkonvergencija će također dobro funkcionirati.
- Tamo gdje je horizontalno skaliranje veći prioritet od okomitog skaliranja, GCS će i tamo dobro poslužiti.
Koja su to rješenja?
- Sve standardne infrastrukturne usluge (imenički servis, pošta, EDMS, datotečni poslužitelji, mali ili srednji ERP i BI sustavi itd.). To nazivamo "općim računalstvom".
- Infrastruktura cloud providera, gdje je potrebno brzo i standardizirano horizontalno proširiti i lako “srezati” veliki broj virtualnih strojeva za klijente.
- Infrastruktura virtualne radne površine (VDI), gdje mnogi mali korisnički virtualni strojevi rade i tiho "lebde" unutar jedinstvenog klastera.
- Mreže podružnica, gdje svaka podružnica treba standardnu, otpornu na pogreške, ali jeftinu infrastrukturu od 15-20 virtualnih strojeva.
- Svako distribuirano računalstvo (usluge velikih podataka, na primjer). Gdje teret ide ne "u dubinu", već "u širinu".
- Testna okruženja u kojima su dodatna mala kašnjenja prihvatljiva, ali postoje proračunska ograničenja jer su to testovi.
Trenutno smo za te zadatke napravili AERODISK vAIR i na njih se fokusiramo (za sada uspješno). Možda će se to uskoro promijeniti, jer... svijet ne stoji.
Tako…
Ovime je završen prvi dio velike serije članaka, au sljedećem ćemo članku govoriti o arhitekturi rješenja i korištenim komponentama.
Pozdravljamo pitanja, prijedloge i konstruktivne rasprave.
Izvor: www.habr.com