Pozdrav, čitaoci Habra. Ovim člankom otvaramo seriju koja će govoriti o hiperkonvergentnom sistemu AERODISK vAIR koji smo razvili. U početku smo hteli da o svemu ispričamo sve u prvom članku, ali sistem je prilično složen, pa ćemo slona jesti u delovima.
Počnimo priču sa istorijom nastanka sistema, udubimo se u sistem datoteka ARDFS, koji je osnova vAIR-a, a takođe malo pričamo o pozicioniranju ovog rešenja na ruskom tržištu.
U budućim člancima ćemo detaljnije govoriti o različitim arhitektonskim komponentama (klaster, hipervizor, balansator opterećenja, sistem za praćenje, itd.), procesu konfiguracije, pokretanju pitanja licenciranja, odvojeno prikazivati crash testove i, naravno, pisati o testiranju opterećenja i dimenzionisanje. Također ćemo posvetiti poseban članak verziji vAIR-a za zajednicu.
Da li je Aerodisk priča o sistemima za skladištenje podataka? Ili zašto smo uopće počeli raditi hiperkonvergenciju?
U početku, ideja o stvaranju vlastite hiperkonvergencije došla nam je negdje oko 2010. godine. U to vrijeme na tržištu nije postojao ni Aerodisk ni slična rješenja (komercijalni kutirani hiperkonvergentni sistemi). Naš zadatak je bio sljedeći: od skupa servera s lokalnim diskovima, ujedinjenih interkonekcijom preko Ethernet protokola, bilo je potrebno napraviti prošireno skladište i tamo pokrenuti virtualne mašine i softversku mrežu. Sve ovo je moralo biti implementirano bez sistema za skladištenje podataka (jer jednostavno nije bilo novca za sisteme za skladištenje podataka i njihov hardver, a još nismo izmislili sopstvene sisteme za skladištenje podataka).
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 ga je ponoviti. Osim toga, ovo rješenje je bilo u kategoriji „Da li radi? Ne diraj! Stoga, riješivši taj problem, nismo dalje razvijali ideju transformacije rezultata našeg rada u punopravni proizvod.
Nakon tog incidenta smo se udaljili od ove ideje, ali smo i dalje imali osjećaj da je ovaj problem u potpunosti rješiv, a koristi od takvog rješenja bile su više nego očigledne. Kasnije su objavljeni HCI proizvodi stranih kompanija samo potvrdili ovaj osjećaj.
Stoga smo se sredinom 2016. vratili ovom zadatku u sklopu stvaranja punopravnog proizvoda. Tada još nismo imali nikakve odnose sa investitorima, pa smo morali da kupimo razvojni štand za svoje ne baš velike pare. Sakupivši rabljene servere i prekidače na Avitu, prionuli smo poslu.
Glavni početni zadatak bio je kreiranje vlastitog, doduše jednostavnog, ali vlastitog sistema datoteka, koji bi mogao automatski i ravnomjerno distribuirati podatke u obliku virtuelnih blokova na n-ti broj čvorova klastera, koji su povezani interkonekcijom preko Etherneta. U isto vrijeme, FS treba dobro i lako skalirati i biti nezavisan od susjednih sistema, tj. biti otuđen od VAIR-a u obliku “samo skladišnog objekta”.
Prvi vAIR koncept
Namjerno smo odustali od upotrebe gotovih open source rješenja za organiziranje stretched storage-a (ceph, gluster, luster i slično) u korist vlastitog razvoja, budući da smo već imali dosta projektnog iskustva s njima. Naravno, ova rješenja su sama po sebi odlična, a prije rada na Aerodisk-u, implementirali smo više od jednog projekta integracije s njima. Ali jedna je stvar implementirati konkretan zadatak za jednog kupca, obučiti osoblje i, možda, kupiti podršku velikog dobavljača, a sasvim druga stvar stvoriti proizvod koji se lako replicira koji će se koristiti za različite zadatke, što mi kao prodavac, možda nećemo ni znati za sebe. Za drugu svrhu, postojeći open source proizvodi nam nisu odgovarali, pa smo odlučili da sami kreiramo distribuirani sistem datoteka.
Dve godine kasnije, nekoliko programera (koji su kombinovali rad na vAIR-u sa radom na klasičnom sistemu za skladištenje motora) postigli su određeni rezultat.
Do 2018. smo napisali jednostavan sistem datoteka i dopunili ga potrebnim hardverom. Sistem je kombinovao fizičke (lokalne) diskove sa različitih servera u jedan ravni bazen preko interne interkonekcije i „isjekao“ ih na virtuelne blokove, a zatim su od virtuelnih blokova kreirani blok uređaji sa različitim stepenom tolerancije grešaka, na kojima su kreirani virtuelni. i izvršava se pomoću KVM hipervizora automobila.
Nismo se previše zamarali imenom fajl sistema i jezgrovito smo ga nazvali ARDFS (pogodite šta znači))
Ovaj prototip je izgledao dobro (ne vizuelno, naravno, vizuelnog dizajna još nije bilo) i pokazao je dobre rezultate u pogledu performansi i skaliranja. Nakon prvog pravog rezultata, pokrenuli smo ovaj projekat, organizirajući potpuno razvojno okruženje i poseban tim koji se bavio samo vAIR-om.
Upravo do tada je sazrela opšta arhitektura rešenja, koja još nije pretrpela veće promene.
Zaroniti u ARDFS sistem datoteka
ARDFS je osnova vAIR-a, koji pruža distribuirano skladištenje podataka otpornih na greške u cijelom klasteru. Jedna od (ali ne i jedina) karakteristična karakteristika ARDFS-a je da ne koristi nikakve dodatne namenske servere za metapodatke i upravljanje. Ovo je prvobitno zamišljeno da pojednostavi konfiguraciju rješenja i radi njegove pouzdanosti.
Struktura skladištenja
Unutar svih čvorova klastera, ARDFS organizira logičko spremište iz cijelog dostupnog prostora na disku. Važno je shvatiti da bazen još nije podaci ili formatirani prostor, već jednostavno označavanje, tj. Svi čvorovi s instaliranim vAIR-om, kada se dodaju u klaster, automatski se dodaju u dijeljeno ARDFS spremište i diskovni resursi se automatski dijele na cijelom klasteru (i dostupni za buduću pohranu podataka). Ovaj pristup vam omogućava da dodajete i uklanjate čvorove u hodu bez ikakvog ozbiljnog uticaja na već pokrenuti sistem. One. sistem je vrlo lako skalirati "u cigle", dodajući ili uklanjajući čvorove u klasteru ako je potrebno.
Virtuelni diskovi (skladišni objekti za virtuelne mašine) dodaju se na vrh ARDFS bazena, koji su napravljeni od virtuelnih blokova veličine 4 megabajta. Virtuelni diskovi direktno pohranjuju podatke. Šema tolerancije grešaka je također postavljena na razini virtualnog diska.
Kao što ste možda već pretpostavili, za toleranciju grešaka podsistema diska, ne koristimo koncept RAID (Redundantni niz nezavisnih diskova), već koristimo RAIN (Redundantni niz nezavisnih čvorova). One. Tolerancija grešaka se mjeri, automatizira i upravlja na osnovu čvorova, a ne diskova. Diskovi su, naravno, i 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 posebno na čvorovima.
U situaciji u kojoj zaista želite RAID (na primjer, scenario 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 scenario je prilično aktivan i podržavamo ga, pa ćemo o njemu govoriti u članku o tipičnim scenarijima za korištenje vAIR-a.
Šeme tolerancije grešaka u skladištenju
Mogu postojati dvije sheme tolerancije grešaka za virtuelne diskove u vAIR-u:
1) Faktor replikacije ili jednostavno replikacija - ova metoda tolerancije grešaka je jednostavna kao štap i konopac. Sinhrona replikacija se izvodi između čvorova s faktorom 2 (2 kopije po klasteru) ili 3 (3 kopije, respektivno). RF-2 omogućava virtuelnom disku da izdrži kvar jednog čvora u klasteru, ali "pojede" polovinu korisnog volumena, a RF-3 će izdržati kvar 2 čvora u klasteru, ali zadržava 2/3 korisna zapremina za svoje potrebe. Ova šema je vrlo slična RAID-1, odnosno virtuelni disk konfigurisan u RF-2 otporan je na kvar bilo kog čvora u klasteru. U ovom slučaju, sve će biti u redu s podacima, pa čak ni I/O neće stati. Kada se pali čvor vrati u rad, automatski oporavak/sinhronizacija podataka će početi.
Ispod su primjeri distribucije RF-2 i RF-3 podataka u normalnom načinu rada iu situaciji kvara.
Imamo virtuelnu mašinu kapaciteta 8MB jedinstvenih (korisnih) podataka, koja radi na 4 vAIR čvora. Jasno je da je u stvarnosti malo vjerovatno da će postojati tako mali volumen, ali za shemu koja odražava logiku rada ARDFS-a, ovaj primjer je najrazumljiviji. AB su virtuelni blokovi od 4MB koji sadrže jedinstvene podatke virtuelne mašine. RF-2 kreira dvije kopije ovih blokova A1+A2 i B1+B2, respektivno. Ovi blokovi su „raspoređeni” po čvorovima, izbjegavajući ukrštanje istih podataka na istom čvoru, odnosno kopija A1 se neće nalaziti na istom čvoru kao kopija A2. Isto je sa B1 i B2.
Ako jedan od čvorova otkaže (na primjer, čvor br. 3, koji sadrži kopiju B1), ova kopija se automatski aktivira na čvoru gdje nema kopije njegove kopije (tj. kopije B2).
Dakle, virtuelni disk (i VM, shodno tome) može lako preživjeti kvar jednog čvora u RF-2 šemi.
Shema replikacije, iako jednostavna i pouzdana, pati od istog problema kao i RAID1 - nema dovoljno korisnog prostora.
2) Kodiranje za brisanje ili kodiranje za brisanje (takođe poznato kao “redundantno kodiranje”, “kodiranje za brisanje” ili “kod redundanse”) postoji da bi riješilo gornji problem. EC je redundantna shema koja osigurava visoku dostupnost podataka sa manjim opterećenjem prostora na disku u usporedbi s replikacijom. Princip rada ovog mehanizma je sličan RAID 5, 6, 6P.
Prilikom kodiranja, EC proces dijeli virtuelni blok (4MB prema zadanim postavkama) na nekoliko manjih "komada podataka" ovisno o EC shemi (na primjer, 2+1 šema dijeli svaki blok od 4MB na 2 dijela od 2MB). Zatim, ovaj proces generiše “paritetne dijelove” za “komponente podataka” koji nisu veći od jednog od prethodno podijeljenih dijelova. Prilikom dekodiranja, EC generiše dijelove koji nedostaju čitajući "preživjele" podatke u cijelom klasteru.
Na primjer, virtuelni disk sa 2 + 1 EC šemom, implementiran na 4 čvora klastera, lako će izdržati kvar jednog čvora u klasteru na isti način kao RF-2. U ovom slučaju, režijski troškovi će biti manji, posebno, koeficijent korisnog kapaciteta za RF-2 je 2, a za EC 2+1 će biti 1,5.
Da to jednostavnije opišemo, suština je da je virtuelni blok podijeljen 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 su ravnomjerno raspoređeni na sve čvorove klastera. Istovremeno, kao i kod replikacije, ARDFS automatski distribuira podatke po č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 iznenada završiti na jednom skladišnom čvoru koji pokvari.
Ispod je primjer, sa istom virtuelnom mašinom od 8 MB i 4 čvora, ali sa EC 2+1 šemom.
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 virtuelni blok A, podeljen na dva dela, isto kao i blok B. Ukupno dobijamo dva seta od 4MB, od kojih svaki sadrži dva dela od dva MB. Zatim se za svaki od ovih skupova izračunava paritet sa zapreminom ne većom od jednog komada (tj. 2 MB), dobijamo 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 sijeku s njihovim paritetom. One. A1 i A2 neće biti na istom čvoru kao AP.
U slučaju kvara jednog čvora (na primjer, i trećeg), pali blok B1 će se automatski vratiti iz BP pariteta, koji je pohranjen na čvoru br. 2, te će se aktivirati na čvoru gdje postoji nema B-pariteta, tj. komad BP. U ovom primjeru, ovo je čvor br. 1
Siguran sam da čitalac ima pitanje:
“Sve što ste opisali već dugo implementiraju konkurenti i rješenja otvorenog koda, koja je razlika između vaše implementacije EC u ARDFS?”
A onda će biti zanimljivih karakteristika ARDFS-a.
Brisanje kodiranja s fokusom na fleksibilnost
U početku smo dali prilično fleksibilnu EC X+Y shemu, gdje je X jednak broju od 2 do 8, a Y je jednak broju od 1 do 8, ali uvijek manji ili jednak X. Ova shema je data za fleksibilnost. Povećanje broja podataka (X) na koje se dijeli virtualni blok omogućava smanjenje režijskih troškova, odnosno povećanje korisnog prostora.
Povećanje broja paritetnih komada (Y) povećava pouzdanost virtuelnog diska. Što je veća Y vrijednost, više čvorova u klasteru može otkazati. Naravno, povećanje volumena pariteta smanjuje količinu korisnog kapaciteta, ali to je cijena koju treba platiti za pouzdanost.
Ovisnost performansi od EC kola je gotovo direktna: što je više „komada”, to su performanse niže; ovdje je, naravno, potreban uravnotežen pogled.
Ovaj pristup omogućava administratorima da konfigurišu rastegnuto skladištenje uz maksimalnu fleksibilnost. Unutar ARDFS bazena možete koristiti bilo koje sheme tolerancije grešaka i njihove kombinacije, što je, po našem mišljenju, također vrlo korisno.
Ispod je tabela koja upoređuje nekoliko (ne svih mogućih) RF i EC šema.
Tabela pokazuje da čak i „frotir“ kombinacija EC 8+7, koja omogućava gubitak do 7 čvorova u klasteru istovremeno, „jede“ manje korisnog prostora (1,875 naspram 2) od standardne replikacije i štiti 7 puta bolje , što ovaj zaštitni mehanizam, iako složeniji, čini znatno atraktivnijim u situacijama kada je potrebno osigurati maksimalnu pouzdanost u uslovima ograničenog prostora na disku. Istovremeno, morate shvatiti 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 vrlo pažljivo birati. Iz tog razloga, mi ćemo posvetiti poseban članak brisanju veličine kodiranja.
Pouzdanost i autonomija sistema datoteka
ARDFS radi lokalno na svim čvorovima klastera i sinkronizira ih koristeći vlastita sredstva putem namjenskih Ethernet sučelja. Važna stvar je da ARDFS nezavisno sinhronizuje ne samo podatke, već i metapodatke koji se odnose na skladištenje. Radeći na ARDFS-u, istovremeno smo proučavali niz postojećih rješenja i otkrili da mnoga sinhroniziraju meta fajl sistema koristeći eksterni distribuirani DBMS, koji također koristimo za sinhronizaciju, ali samo konfiguracije, a ne FS metapodatke (o ovom i drugim srodnim podsistemima u sljedećem članku).
Sinhronizacija FS metapodataka pomoću eksternog 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), koji u naše mišljenje je loše. Zašto? Ako se FS metapodaci oštete, sami FS podaci se takođe mogu reći "zbogom", pa smo odlučili da krenemo složenijim, ali pouzdanijim putem.
Sami smo napravili podsistem za sinhronizaciju metapodataka za ARDFS i on živi potpuno nezavisno od susednih podsistema. One. nijedan drugi podsistem ne može oštetiti ARDFS podatke. Po našem mišljenju, ovo je najpouzdaniji i najispravniji način, ali vrijeme će pokazati da li je to zaista tako. Osim toga, postoji dodatna prednost kod ovog pristupa. ARDFS se može koristiti nezavisno od vAIR-a, baš kao i rastegnuto skladište, što ćemo sigurno koristiti u budućim proizvodima.
Kao rezultat toga, razvojem ARDFS-a, dobili smo fleksibilan i pouzdan sistem datoteka koji daje izbor gdje možete uštedjeti na kapacitetu ili odustati od svega na performansama, ili napraviti ultra-pouzdan prostor za skladištenje po razumnoj cijeni, ali smanjujući zahtjeve za performansama.
Zajedno sa jednostavnom politikom licenciranja i fleksibilnim modelom isporuke (gledajući unaprijed, vAIR se licencira po čvoru i isporučuje se ili kao softver ili kao softverski paket), ovo omogućava vrlo precizno prilagođavanje rješenja širokom spektru zahtjeva korisnika i onda lako održavati 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 u oblasti hiperkonvergencije i tu zapravo idemo. Čini se da je ova izjava tač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, na nekim mjestima ljudi jednostavno nisu znali da postoje takva rješenja, na nekima se činilo skupim, na trećima je bilo neuspješnih testiranja alternativnih rješenja, a na nekima uopće zabranjuju kupovinu zbog sankcija. Općenito, ispostavilo se da je polje neorano, pa smo otišli da podignemo devičansko tlo))).
Kada je sistem skladištenja bolji od GKS-a?
Dok radimo sa tržištem, često nas pitaju kada je bolje koristiti klasičnu šemu sa sistemima za skladištenje podataka, a kada hiperkonvergentnu? Mnoge kompanije koje proizvode GCS (posebno one koje nemaju sisteme za skladištenje u svom portfelju) kažu: „Skladišni sistemi postaju zastareli, samo hiperkonvergirani!“ Ovo je hrabra izjava, ali ne odražava u potpunosti stvarnost.
Istina, tržište skladišta se zaista kreće ka hiperkonvergenciji i sličnim rješenjima, ali uvijek postoji “ali”.
Prvo, data centri i IT infrastrukture izgrađene po klasičnoj šemi sa sistemima za skladištenje podataka ne mogu se lako obnoviti, pa je modernizacija i završetak takvih infrastruktura i dalje naslijeđe za 5-7 godina.
Drugo, infrastruktura koja se trenutno gradi najvećim dijelom (misli se na Rusku Federaciju) izgrađena je po klasičnoj shemi koristeći skladišne sisteme, 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 treba da grade data centre ovdje i sada. I ovaj trend će trajati još 3-5 godina (i onda još jedno naslijeđe, vidi tačku 1).
Treće, postoji čisto tehničko ograničenje u dodatnim malim kašnjenjima od 2 milisekunde po pisanju (isključujući lokalnu keš memoriju, naravno), koja su plaćanje za distribuiranu pohranu.
Pa, ne zaboravimo na korištenje velikih fizičkih servera koji vole vertikalno skaliranje diskovnog podsistema.
Postoji mnogo neophodnih i popularnih zadataka u kojima se sistemi za skladištenje ponašaju bolje od GCS-a. Ovdje se, naravno, neće složiti s nama oni proizvođači koji nemaju sisteme za skladištenje u svom proizvodnom portfelju, ali mi smo spremni razumno raspravljati. Naravno, mi, kao programeri oba proizvoda, svakako ćemo uporediti sisteme za skladištenje i GCS u nekoj od naših budućih publikacija, gde ćemo jasno pokazati šta je bolje pod kojim uslovima.
A gdje će hiperkonvergentna rješenja raditi bolje od sistema za skladištenje podataka?
Na osnovu gore navedenih tačaka, mogu se izvući tri očigledna zaključka:
- Tamo gdje su dodatne 2 milisekunde latencije za snimanje, koje se konstantno javljaju u bilo kojem proizvodu (sada ne govorimo o sintetici, nanosekunde se mogu prikazati na sintetici), nisu kritične, prikladan je hiperkonvergentni.
- Tamo gdje se opterećenje s velikih fizičkih servera može pretvoriti u mnogo malih virtualnih i distribuirati među čvorovima, hiperkonvergencija će također dobro funkcionirati.
- Tamo gdje je horizontalno skaliranje veći prioritet od vertikalnog skaliranja, GKS će također odlično raditi.
Koja su to rješenja?
- Sve standardne infrastrukturne usluge (usluga imenika, pošte, EDMS, fajl serveri, mali ili srednji ERP i BI sistemi, itd.). Mi to zovemo "opšte računanje".
- Infrastrukturu provajdera u oblaku, gde je potrebno brzo i standardizovano horizontalno proširiti i lako „iseći“ veliki broj virtuelnih mašina za klijente.
- Infrastruktura virtuelne radne površine (VDI), gde mnoge male korisničke virtuelne mašine rade i tiho „plutaju“ unutar uniformnog klastera.
- Mreže podružnica, gdje je svakoj grani potrebna standardna, otporna na greške, ali jeftina infrastruktura od 15-20 virtuelnih mašina.
- Bilo koje distribuirano računarstvo (usluge velikih podataka, na primjer). Gdje opterećenje ne ide „u dubinu“, već „u širinu“.
- Testna okruženja u kojima su dodatna mala kašnjenja prihvatljiva, ali postoje ograničenja budžeta, jer su to testovi.
Trenutno smo upravo za ove zadatke napravili AERODISK vAIR i na njih se (do sada uspješno) fokusiramo. Možda će se to uskoro promijeniti, jer... svijet ne miruje.
Pa ...
Ovim je završen prvi dio velike serije članaka; u sljedećem članku ćemo govoriti o arhitekturi rješenja i korištenim komponentama.
Pozdravljamo pitanja, sugestije i konstruktivne sporove.
izvor: www.habr.com