Pozdravljeni bralci Habra. S tem člankom odpiramo serijo, ki bo govorila o hiperkonvergiranem sistemu AERODISK vAIR, ki smo ga razvili. Sprva smo želeli povedati vse o vsem v prvem članku, vendar je sistem precej zapleten, zato bomo slona jedli po delih.
Začnimo zgodbo z zgodovino nastanka sistema, poglobimo se v datotečni sistem ARDFS, ki je osnova vAIR, in se malo pogovorimo o pozicioniranju te rešitve na ruskem trgu.
V prihodnjih člankih bomo podrobneje govorili o različnih arhitekturnih komponentah (gruča, hipervizor, izravnalnik obremenitve, nadzorni sistem itd.), konfiguracijskem procesu, izpostavili vprašanja licenciranja, ločeno prikazali teste trčenja in seveda pisali o testiranju obremenitve in dimenzioniranje. Ločen članek bomo posvetili tudi skupnostni različici vAIR.
Je Aerodisk zgodba o sistemih za shranjevanje? Ali zakaj smo sploh začeli izvajati hiperkonvergenco?
Sprva se nam je ideja o ustvarjanju lastne hiperkonvergence porodila nekje okoli leta 2010. Takrat na trgu še ni bilo ne Aerodiska ne podobnih rešitev (komercialnih škatlastih hiperkonvergiranih sistemov). Naša naloga je bila naslednja: iz nabora strežnikov z lokalnimi diski, ki jih povezuje medsebojna povezava preko Ethernet protokola, je bilo treba ustvariti razširjeno shrambo in tam zagnati virtualne stroje in programsko omrežje. Vse to je bilo treba izvesti brez shranjevalnih sistemov (ker preprosto ni bilo denarja za shranjevalne sisteme in njihovo strojno opremo, lastnih shranjevalnih sistemov pa še nismo iznašli).
Preizkusili smo veliko odprtokodnih rešitev in končno rešili ta problem, vendar je bila rešitev zelo kompleksna in težko ponovljiva. Poleg tega je bila ta rešitev v kategoriji »Ali deluje? Ne dotikaj se! Zato po rešitvi tega problema nismo nadalje razvijali ideje o pretvorbi rezultata našega dela v polnopravni izdelek.
Po tistem incidentu smo se od te ideje oddaljili, a smo še vedno imeli občutek, da je ta problem povsem rešljiv, prednosti takšne rešitve pa več kot očitne. Pozneje so izdani izdelki HCI tujih podjetij le potrdili ta občutek.
Zato smo se sredi leta 2016 vrnili k tej nalogi v okviru ustvarjanja polnopravnega produkta. Takrat še nismo imeli nobenih odnosov z investitorji, zato smo morali razvojno stojalo kupiti za lasten, ne prav velik denar. Po zbiranju rabljenih strežnikov in stikal na Avitu smo se lotili posla.
Glavna začetna naloga je bila izdelava lastnega, sicer preprostega, a lastnega datotečnega sistema, ki bi lahko samodejno in enakomerno porazdelil podatke v obliki virtualnih blokov na n-to število vozlišč gruče, ki so med seboj povezana preko Etherneta. Hkrati bi moral FS dobro in enostavno skalirati in biti neodvisen od sosednjih sistemov, tj. odtujiti od vAIR v obliki »samo skladišča«.
Prvi koncept vAIR
Namenoma smo opustili uporabo že pripravljenih odprtokodnih rešitev za organizacijo raztegnjenega skladišča (ceph, gluster, luster in podobno) v korist lastnega razvoja, saj smo imeli z njimi že veliko projektnih izkušenj. Seveda so same te rešitve odlične in pred začetkom Aerodiska smo z njimi izvedli več kot en integracijski projekt. Toda ena stvar je izvajati določeno nalogo za eno stranko, usposobiti osebje in morda kupiti podporo velikega prodajalca, čisto nekaj drugega pa je ustvariti izdelek, ki ga je enostavno ponoviti in bo uporabljen za različne naloge, ki jih kot prodajalca, morda celo vedeli o sebi ne bomo. Za drugi namen nam obstoječi odprtokodni produkti niso ustrezali, zato smo se odločili sami izdelati porazdeljeni datotečni sistem.
Dve leti pozneje je več razvijalcev (ki so združevali delo na vAIR z delom na klasičnem sistemu za shranjevanje Engine) doseglo določen rezultat.
Do leta 2018 smo napisali preprost datotečni sistem in ga dopolnili s potrebno strojno opremo. Sistem je združil fizične (lokalne) diske iz različnih strežnikov v en flat pool prek notranje povezave in jih "razrezal" v virtualne bloke, nato pa so iz virtualnih blokov ustvarili blokovne naprave z različnimi stopnjami tolerance napak, na katerih so nastale virtualne in se izvede z uporabo avtomobilov hipervizorja KVM.
Z imenom datotečnega sistema se nismo preveč obremenjevali in smo ga na kratko poimenovali ARDFS (uganite, kaj to pomeni))
Ta prototip je bil videti dobro (seveda ne vizualno, vizualne zasnove še ni bilo) in je pokazal dobre rezultate v smislu zmogljivosti in skaliranja. Po prvem pravem rezultatu smo ta projekt zagnali z organizacijo polnopravnega razvojnega okolja in ločene ekipe, ki se je ukvarjala samo z vAIR.
Ravno takrat je dozorela splošna arhitektura rešitve, ki še ni doživela večjih sprememb.
Potop v datotečni sistem ARDFS
ARDFS je temelj vAIR, ki zagotavlja porazdeljeno shranjevanje podatkov, odporno na napake, v celotni gruči. Ena izmed (vendar ne edina) značilnost ARDFS je, da ne uporablja nobenih dodatnih namenskih strežnikov za metapodatke in upravljanje. To je bilo prvotno zasnovano za poenostavitev konfiguracije rešitve in za njeno zanesljivost.
Struktura shranjevanja
Znotraj vseh vozlišč gruče ARDFS organizira logično skupino iz vsega razpoložljivega prostora na disku. Pomembno je razumeti, da bazen še ni podatek ali formatiran prostor, ampak preprosto oznaka, tj. Vsa vozlišča z nameščenim vAIR, ko so dodana v gručo, so samodejno dodana v skupino ARDFS v skupni rabi in diskovni viri se samodejno delijo v celotni gruči (in so na voljo za prihodnje shranjevanje podatkov). Ta pristop vam omogoča sprotno dodajanje in odstranjevanje vozlišč brez resnega vpliva na že delujoč sistem. Tisti. sistem je zelo enostavno skalirati "v kockah", z dodajanjem ali odstranjevanjem vozlišč v gruči, če je potrebno.
Na vrh bazena ARDFS so dodani virtualni diski (shranjevalni objekti za virtualne stroje), ki so zgrajeni iz virtualnih blokov velikosti 4 megabajtov. Virtualni diski neposredno shranjujejo podatke. Shema tolerance napak je nastavljena tudi na ravni virtualnega diska.
Kot ste morda že uganili, za odpornost na napake diskovnega podsistema ne uporabljamo koncepta RAID (odvečno polje neodvisnih diskov), temveč RAIN (odvečno polje neodvisnih vozlišč). Tisti. Toleranca napak se meri, avtomatizira in upravlja na podlagi vozlišč, ne diskov. Diski so seveda tudi pomnilniški objekt, tako kot vse ostalo so nadzorovani, z njimi lahko izvajate vse standardne operacije, vključno z sestavljanjem lokalnega strojnega RAID-a, vendar grozd deluje posebej na vozliščih.
V situaciji, ko resnično želite RAID (na primer scenarij, ki podpira večkratne napake v majhnih gručih), vam nič ne preprečuje uporabe lokalnih krmilnikov RAID in gradnje raztegnjenega pomnilnika in arhitekture RAIN na vrhu. Ta scenarij je precej živ in ga podpiramo, zato bomo o njem govorili v članku o tipičnih scenarijih za uporabo vAIR.
Sheme tolerance napak pri shranjevanju
Za virtualne diske v vAIR lahko obstajata dve shemi tolerance napak:
1) Replikacijski faktor ali preprosto replikacija - ta metoda tolerance napak je preprosta kot palica in vrv. Sinhrono podvajanje se izvaja med vozlišči s faktorjem 2 (2 kopiji na gručo) ali 3 (3 kopije oz.). RF-2 omogoča, da virtualni disk prenese odpoved enega vozlišča v gruči, vendar "poje" polovico uporabne prostornine, RF-3 pa prenese odpoved 2 vozlišč v gruči, vendar rezervira 2/3 uporabno količino za svoje potrebe. Ta shema je zelo podobna RAID-1, kar pomeni, da je virtualni disk, konfiguriran v RF-2, odporen na okvaro katerega koli vozlišča v gruči. V tem primeru bo s podatki vse v redu in tudi I/O se ne bo ustavil. Ko se okvarjeno vozlišče vrne v delovanje, se začne samodejno obnavljanje/sinhronizacija podatkov.
Spodaj so primeri porazdelitve podatkov RF-2 in RF-3 v običajnem načinu in v primeru okvare.
Imamo virtualni stroj s kapaciteto 8 MB unikatnih (uporabnih) podatkov, ki teče na 4 vozliščih vAIR. Jasno je, da je v resnici malo verjetno, da bo tako majhen obseg, toda za shemo, ki odraža logiko delovanja ARDFS, je ta primer najbolj razumljiv. AB so 4 MB navidezni bloki, ki vsebujejo edinstvene podatke o navideznem stroju. RF-2 ustvari dve kopiji teh blokov A1+A2 oziroma B1+B2. Ti bloki so "razporejeni" po vozliščih, pri čemer se izognejo presečišču istih podatkov na istem vozlišču, kar pomeni, da kopija A1 ne bo na istem vozlišču kot kopija A2. Enako z B1 in B2.
Če eno od vozlišč odpove (na primer vozlišče št. 3, ki vsebuje kopijo B1), se ta kopija samodejno aktivira na vozlišču, kjer ni kopije njegove kopije (to je kopija B2).
Tako lahko virtualni disk (in v skladu s tem VM) zlahka preživi napako enega vozlišča v shemi RF-2.
Čeprav je shema podvajanja preprosta in zanesljiva, se sooča z enako težavo kot RAID1 – premalo uporabnega prostora.
2) Kodiranje za izbris ali kodiranje za izbris (znano tudi kot "odvečno kodiranje", "kodiranje za izbris" ali "odvečna koda") obstaja za rešitev zgornje težave. EC je shema redundance, ki zagotavlja visoko razpoložljivost podatkov z manjšo količino prostora na disku v primerjavi s podvajanjem. Načelo delovanja tega mehanizma je podobno kot pri RAID 5, 6, 6P.
Pri kodiranju postopek EC razdeli virtualni blok (privzeto 4 MB) na več manjših "podatkovnih kosov", odvisno od sheme EC (na primer shema 2+1 razdeli vsak 4 MB blok na 2 kosa po 2 MB). Nato ta postopek ustvari "paritetne kose" za "podatkovne kose", ki niso večji od enega od prej razdeljenih delov. Pri dekodiranju EC ustvari manjkajoče dele tako, da prebere "preživele" podatke v celotni gruči.
Na primer, virtualni disk s shemo 2 + 1 EC, implementiran na 4 vozliščih gruče, bo zlahka prenesel okvaro enega vozlišča v gruči na enak način kot RF-2. V tem primeru bodo režijski stroški nižji, predvsem je koeficient koristne zmogljivosti za RF-2 2, za EC 2+1 pa 1,5.
Preprosteje rečeno, bistvo je, da je virtualni blok razdeljen na 2-8 (zakaj od 2 do 8, glej spodaj) "kosov", za te kose pa se izračunajo "kosi" paritete podobnega obsega.
Posledično so podatki in pariteta enakomerno porazdeljeni po vseh vozliščih gruče. Istočasno, tako kot pri replikaciji, ARDFS samodejno razdeli podatke med vozlišča na tak način, da prepreči shranjevanje enakih podatkov (kopije podatkov in njihove paritete) na istem vozlišču, da se odpravi možnost izgube podatkov zaradi na dejstvo, da bodo podatki in njihova pariteta nenadoma končali na enem pomnilniškem vozlišču, ki ne uspe.
Spodaj je primer z istim 8 MB navideznim strojem in 4 vozlišči, vendar s shemo EC 2+1.
Bloka A in B sta razdeljena na dva dela po 2 MB (dva, ker 2+1), to sta A1+A2 in B1+B2. Za razliko od replike, A1 ni kopija A2, je virtualni blok A, razdeljen na dva dela, enako je z blokom B. Skupaj dobimo dva niza po 4 MB, od katerih vsak vsebuje dva kosa po dva MB. Nato se za vsakega od teh nizov izračuna pariteta z volumnom največ enega kosa (t.j. 2 MB), dobimo dodatno + 2 kosa paritete (AP in BP). Skupaj imamo podatke 4 × 2 + parnost 2 × 2.
Nato so deli "razporejeni" med vozlišči, tako da se podatki ne sekajo z njihovo pariteto. Tisti. A1 in A2 ne bosta na istem vozlišču kot AP.
V primeru okvare enega vozlišča (npr. tudi tretjega) se padli blok B1 samodejno obnovi iz paritete BP, ki je shranjena na vozlišču št. 2, in se aktivira na vozlišču, kjer je ni B-paritete, tj. kos BP. V tem primeru je to vozlišče št. 1
Prepričan sem, da ima bralec vprašanje:
"Vse, kar ste opisali, že dolgo izvajajo tako konkurenti kot odprtokodne rešitve, kakšna je razlika med vašo implementacijo EC v ARDFS?"
In potem bodo zanimive funkcije ARDFS.
Kodiranje za brisanje s poudarkom na prilagodljivosti
Na začetku smo zagotovili dokaj prilagodljivo shemo EC X+Y, kjer je X enak številu od 2 do 8, Y pa je enak številu od 1 do 8, vendar vedno manjši ali enak X. Ta shema je na voljo za prilagodljivost. Povečanje števila podatkovnih kosov (X), na katere je razdeljen virtualni blok, omogoča zmanjšanje režijskih stroškov, to je povečanje uporabnega prostora.
Povečanje števila paritetnih kosov (Y) poveča zanesljivost virtualnega diska. Večja kot je vrednost Y, več vozlišč v gruči lahko odpove. Seveda povečanje paritetnega obsega zmanjša količino uporabne zmogljivosti, vendar je to cena, ki jo je treba plačati za zanesljivost.
Odvisnost zmogljivosti od EC tokokrogov je skoraj neposredna: več "kosov", nižja je zmogljivost; tukaj je seveda potreben uravnotežen pogled.
Ta pristop omogoča skrbnikom, da konfigurirajo raztegnjeno shranjevanje z največjo prilagodljivostjo. Znotraj bazena ARDFS lahko uporabljate poljubne sheme tolerance napak in njihove kombinacije, kar je po našem mnenju tudi zelo uporabno.
Spodaj je tabela s primerjavo več (ne vseh možnih) shem RF in EC.
Iz tabele je razvidno, da tudi najbolj "frotirna" kombinacija EC 8+7, ki omogoča izgubo do 7 vozlišč v gruči hkrati, "poje" manj uporabnega prostora (1,875 proti 2) kot standardna replikacija in ščiti 7-krat bolje. , zaradi česar je ta zaščitni mehanizem, čeprav kompleksnejši, veliko privlačnejši v situacijah, ko je treba zagotoviti maksimalno zanesljivost v razmerah omejenega prostora na disku. Hkrati morate razumeti, da bo vsak "plus" na X ali Y dodaten strošek zmogljivosti, zato morate v trikotniku med zanesljivostjo, prihranki in zmogljivostjo izbrati zelo previdno. Iz tega razloga bomo dimenzioniranju brisalne kode posvetili poseben članek.
Zanesljivost in avtonomnost datotečnega sistema
ARDFS deluje lokalno na vseh vozliščih gruče in jih sinhronizira z lastnimi sredstvi prek namenskih vmesnikov Ethernet. Pomembno je, da ARDFS neodvisno sinhronizira ne le podatke, ampak tudi metapodatke, povezane s shranjevanjem. Med delom na ARDFS smo hkrati preučevali številne obstoječe rešitve in ugotovili, da mnoge sinhronizirajo meta datotečnega sistema z uporabo zunanjega porazdeljenega DBMS, ki ga tudi uporabljamo za sinhronizacijo, vendar le konfiguracije, ne metapodatkov FS (o tem in drugih povezanih podsistemih v naslednjem članku).
Sinhronizacija metapodatkov FS z uporabo zunanjega DBMS je seveda delujoča rešitev, vendar bi bila potem doslednost podatkov, shranjenih na ARDFS, odvisna od zunanjega DBMS in njegovega vedenja (in, odkrito povedano, je muhasta dama), ki v naše mnenje je slabo. Zakaj? Če se metapodatki FS poškodujejo, se lahko sami podatki FS tudi poslovijo, zato smo se odločili za bolj zapleteno, a zanesljivo pot.
Podsistem za sinhronizacijo metapodatkov za ARDFS smo naredili sami in živi popolnoma neodvisno od sosednjih podsistemov. Tisti. noben drug podsistem ne more poškodovati podatkov ARDFS. Po našem mnenju je to najbolj zanesljiv in pravilen način, čas pa bo pokazal, ali je res tako. Poleg tega je s tem pristopom še dodatna prednost. ARDFS lahko uporabljamo neodvisno od vAIR, kot raztegnjeno shranjevanje, ki ga bomo zagotovo uporabili v prihodnjih izdelkih.
Posledično smo z razvojem ARDFS prejeli prilagodljiv in zanesljiv datotečni sistem, ki omogoča izbiro, kjer lahko prihranite pri zmogljivosti ali se odrečete vsemu pri zmogljivosti ali naredite izjemno zanesljivo shranjevanje po razumni ceni, vendar zmanjšate zahteve glede zmogljivosti.
Skupaj s preprosto politiko licenciranja in prilagodljivim modelom dostave (če pogledamo naprej, je vAIR licenciran po vozliščih in dostavljen kot programska oprema ali kot programski paket) vam to omogoča, da zelo natančno prilagodite rešitev najrazličnejšim zahtevam strank in potem zlahka ohranite to ravnovesje.
Kdo potrebuje ta čudež?
Po eni strani lahko rečemo, da na trgu že obstajajo igralci, ki imajo resne rešitve na področju hiperkonvergence, in tja smo pravzaprav usmerjeni. Zdi se, da je ta izjava resnična, AMPAK ...
Po drugi strani pa, ko gremo na teren in komuniciramo s strankami, mi in naši partnerji vidimo, da temu sploh ni tako. Nalog za hiperkonvergenco je veliko, ponekod ljudje preprosto niso vedeli, da takšne rešitve obstajajo, drugje se je zdelo drago, tretjim so bili neuspešni testi alternativnih rešitev, ponekod zaradi sankcij nakup sploh prepovedujejo. Na splošno se je polje izkazalo za nepreorano, zato smo šli dvigniti deviško zemljo))).
Kdaj je sistem za shranjevanje boljši od GCS?
Ko delamo s trgom, se pogosto sprašujemo, kdaj je bolje uporabiti klasično shemo s sistemi za shranjevanje in kdaj uporabiti hiperkonvergentno? Številna podjetja, ki proizvajajo GCS (zlasti tista, ki nimajo sistemov za shranjevanje v svojem portfelju), pravijo: "Sistemi za shranjevanje postajajo zastareli, samo hiperkonvergirani!" To je drzna izjava, vendar ne odraža v celoti realnosti.
V resnici se trg shranjevanja res premika proti hiperkonvergenci in podobnim rešitvam, vendar vedno obstaja "ampak".
Prvič, podatkovnih centrov in IT infrastruktur, zgrajenih po klasični shemi s sistemi za shranjevanje, ni mogoče preprosto obnoviti, zato je posodobitev in dokončanje takšnih infrastruktur še vedno dediščina za 5-7 let.
Drugič, infrastruktura, ki se trenutno gradi večinoma (kar pomeni Ruska federacija), je zgrajena po klasični shemi z uporabo sistemov za shranjevanje, in ne zato, ker ljudje ne poznajo hiperkonvergence, ampak ker je trg hiperkonvergence nov, rešitve in standardi še niso vzpostavljeni, IT-ji še niso usposobljeni, imajo malo izkušenj, vendar morajo podatkovne centre zgraditi tukaj in zdaj. In ta trend bo trajal še 3-5 let (in potem še ena dediščina, glej točko 1).
Tretjič, obstaja čisto tehnična omejitev dodatnih majhnih zakasnitev 2 milisekundi na pisanje (seveda brez lokalnega predpomnilnika), kar je strošek porazdeljenega shranjevanja.
No, ne smemo pozabiti na uporabo velikih fizičnih strežnikov, ki obožujejo vertikalno skaliranje diskovnega podsistema.
Obstaja veliko potrebnih in priljubljenih opravil, pri katerih se sistemi za shranjevanje obnašajo bolje kot GCS. Tukaj se seveda tisti proizvajalci, ki v svojem portfelju izdelkov nimajo sistemov za shranjevanje, ne bodo strinjali z nami, vendar smo pripravljeni razumno trditi. Seveda bomo kot razvijalci obeh produktov zagotovo primerjali skladiščne sisteme in GCS v eni izmed naših prihodnjih publikacij, kjer bomo jasno pokazali, kateri je boljši pod kakšnimi pogoji.
In kje bodo hiperkonvergirane rešitve delovale bolje kot sistemi za shranjevanje?
Na podlagi zgornjih točk je mogoče narediti tri očitne zaključke:
- Kjer sta dodatni 2 milisekundi zakasnitve pri snemanju, ki se dosledno pojavljata pri katerem koli izdelku (sedaj ne govorimo o sintetiki, na sintetiki se lahko prikažejo nanosekunde), nekritični, je primerna hiperkonvergentna.
- Kjer je mogoče obremenitev velikih fizičnih strežnikov spremeniti v številne majhne virtualne strežnike in porazdeliti med vozlišča, bo hiperkonvergenca tudi tam dobro delovala.
- Kjer je horizontalno skaliranje višja prioriteta kot vertikalno skaliranje, bo GCS tudi tam v redu.
Kakšne so te rešitve?
- Vse standardne infrastrukturne storitve (imeniški servis, pošta, EDMS, datotečni strežniki, mali ali srednji ERP in BI sistemi itd.). Temu pravimo »splošno računalništvo«.
- Infrastruktura ponudnikov v oblaku, kjer je potrebno hitro in standardizirano horizontalno razširiti in enostavno “razrezati” večje število virtualnih strojev za stranke.
- Infrastruktura navideznega namizja (VDI), kjer veliko majhnih uporabniških virtualnih strojev deluje in tiho "lebdi" znotraj enotne gruče.
- Podružnična omrežja, kjer vsaka podružnica potrebuje standardno, odporno na napake, a poceni infrastrukturo 15-20 virtualnih strojev.
- Kakršno koli porazdeljeno računalništvo (storitve velikih podatkov, na primer). Kjer breme ne gre "v globino", ampak "v širino".
- Testna okolja, kjer so dodatne majhne zamude sprejemljive, vendar obstajajo proračunske omejitve, ker so to testi.
Trenutno smo za te naloge naredili AERODISK vAIR in se nanje osredotočamo (zaenkrat uspešno). Morda se bo to kmalu spremenilo, saj... svet ne miruje.
Torej ...
S tem smo zaključili prvi del velike serije člankov, v naslednjem članku bomo govorili o arhitekturi rešitve in uporabljenih komponentah.
Veseli bomo vprašanj, predlogov in konstruktivnih sporov.
Vir: www.habr.com