🥇Hüperkonvergente lahendus AERODISK vAIR. Alus — failisüsteem ARDFS

Tere, Habr lugejad. Käesolevaga avame tsükli, mis räägib meie loodud hüperkonvergeeritud süsteemist AERODISK vAIR. Alguses soovisime esimeses artiklis rääkida kõigest, kuid süsteem on üsna keeruline, seega võtame hiire hammustuste kaupa.

Alustame jutuga süsteemi loomise ajaloost, süveneme failisüsteemi ARDFS, mis on vAIR-i alus, ja arutame veidi ka selle lahenduse positsioneerimist Venemaa turul.

Edasistes artiklites räägime lähemalt erinevatest arhitektuurikomponentidest (klaster, hüperviisor, koormuse tasakaalustaja, jälgimissüsteem jne), seadistamisprotsessist, käsitleme litsenseerimise küsimusi, näitame eraldi crash-teste ja loomulikult kirjutame koormustestimisest ja suurusest. Samuti pühendame eraldi artikli vAIR-i community-versioonile.

AERODISK on nagu lugu andmesalvestusseadmest? Miks me üldse hüperkonvergentsiga tegelema hakkasime?

Alguses, umbes 2010. aastal, tuli meile mõte luua oma hübriidkonvergeeritud lahendus. Sel ajal ei olnud turul veel Aerodiski ega sarnaseid (kaubanduslikult pakutavaid hübriidkonvergeeritud süsteeme). Meie ülesanne oli järgmine: muuta rikka serverite komplekt, millel on lokaalsed kettad ja mis on ühendatud Etherneti protokolli kaudu, jaotatud salvestuseks ning sealne virtuaalmasinate ja programmisüsteemi tööks. Kõike seda tuli teostada ilma SID (sest SID peale ja selle varustusele polnud raha, ja oma SID-d me siis veel ei olnud välja mõelnud).

Oleme proovinud palju open source lahendusi ja lõpuks lahendasime selle ülesande, kuid lahendus oli väga keeruline ning seda oli raske korrata. Lisaks oli see lahendus laadi „Kas see töötab? Ära puutu!“. Seetõttu, kuigi oleme selle ülesande lahendanud, ei arendanud me ideed edasi, et muuta meie töö tulemused täieõiguslikuks tooteks.

Pärast seda juhtumit loobusime sellest ideest, kuid tunne, et see ülesanne on lahendatav ja et sellise lahenduse kasu on ilmselge, ei jätnud meid. Edasi liikuvad HCI tooted välisfirmadelt kinnitasid seda tunnet veelgi.

Seetõttu naasime 2016. aasta keskpaiku sellele ülesandele, et luua tõeliselt täielik toode. Toona ei olnud meil veel mingeid suhteid investoritega, mistõttu pidime arendusjaama ostma oma piiratud rahade eest. Ostsime Avitost kasutatud servereid ja lüliteid ning asusime tööle.

Peamine algne ülesanne oli luua oma, kuigi lihtne, failisüsteem, mis suudaks automaatselt ja ühtlaselt jaotada andmeid virtuaalsete blokkide kujul n-arvuliste klastrinoodide vahel, mis on ühendatud Etherneti kaudu. Samuti pidi failisüsteem olema hästi ja lihtsalt skaleeritav ning sõltumatu külgmistest süsteemidest, st olema vAIR-ist eraldatav lihtsalt kui "hoidla".

vAIR-i esimene kontseptsioon

Otsustasime teadlikult loobuda valmiduse avatud lähtekoodiga lahenduste kasutamisest jaotatud salvestuse (ceph, gluster, lustre ja muud sarnased) korraldamiseks ning eelistada oma arendust, kuna olime nendega juba palju projektikogemust omandanud. Ilmselgelt on need lahendused iseenesest suurepärased, ning enne Aerodiski tööle asumist viisime nende abil ellu mitu integreerimisprojekti. Kuid üks asi on täita kindlat kliendi ülesannet, koolitada personali ning võimalusel osta suurelt tarnijalt tugi, ja hoopis teine Asi on luua hõlpsasti replitseeriv toode, mida saab kasutada erinevate ülesannete jaoks, millest meie, kui tarnija, ei pruugi isegi teadlikud olla. Seetõttu otsustasime, et olemasolevad avatud lähtekoodiga tooted ei sobi meie teise eesmärgi jaoks ning niisiis hakkasime ise jaotatud failisüsteemi arendama.
Kaks aastat hiljem saavutasime mitme arendaja (kes ühendasid tööd vAIR-i arendamise ja klassikalise andmesalvestusseadme Engine'i vahel) kaudu teatud tulemuse.

Aastal 2018 lõime me lihtsa failisüsteemi ning täiustasime seda vajalike lisadega. Süsteem ühendab erinevate серверite füüsilised (kohalikud) ketasühendused üheks tasaseks puuks ja „lõikab” need virtuaalseteks plokkideks; seejärel luuakse virtuaalsetest plokkidest erineva tulemuslikkuse ja tõrketaluvuse tasemega plokiseadmised, mille peal kujundatakse ja käitatakse virtuaalmasinad KVM hüperviisori abil.

Failisüsteemi nimi ei olnud meile kuigi oluline, seetõttu nimetame selle lihtsalt ARDFS-iks (arvake, mida see tähistab))

See prototüüp nägi välja hea (loomulikult mitte visuaalselt, sel ajal polnud veel visuaalset kujundust) ja näitas head jõudlust ning skaleeritavust. Pärast esimesi reaalseid tulemusi andsime projektile käigu, korraldades korraliku arenduskeskkonna ja eraldi meeskonna, mis tegeles ainult vAIR-iga.

Just sel ajal valmistas meeleheide üldine lahenduse arhitektuur, mis pole siiani tõsiseid muutusi kogenud.

Sukeldume ARDFS failisüsteemi

ARDFS on vAIR-i aluseks, mis tagab kogu klastri hajutatud rikke kindla andmete salvestamise. Üks (kuid mitte ainus) ARDFS-i eripära on see, et see ei kasuta mingeid lisandusi andmete haldamiseks. dedikeeritud serverite See oli algselt mõeldud lahenduse seadistamise lihtsustamiseks ja usaldusväärsuse tagamiseks.

Salvestusstruktuur

ARDFS korraldab kogu klastri sõlmede raames loogilise puu kogu kergesti kätte saadavast kettaruumist. On oluline mõista, et puu ei ole veel andmed ega vormindatud ruum, vaid lihtsalt tähistus, s.t. iga sõlm, millel on installitud vAIR, lisatakse automaatselt klastri lisamisel ARDFS-i ühisesse puusse ja kettaressursid muutuvad automaatselt kõigi klastri jaoks ühisteks (ja on saadaval edasiste andmete salvestamiseks). Selline lähenemine võimaldab sõlmede lisamist ja eemaldamist sujuvalt ilma, et see tõsiselt mõjutaks juba toimivat süsteemi. See tähendab, et süsteemi on väga lihtne „telliskivina” skaleerida, lisades või eemaldades sõlmi klastris vastavalt vajadusele.

ARDFS-i kohal lisatakse virtuaalsed kettad (salvestusobjektid virtuaalmasinate jaoks), mis on koostatud 4 megabaiti suurustest virtuaalsetest blokidest. Virtuaalsetel kettadel salvestatakse andmed otse. Virtuaalsete kettaste tasandil kehtestatakse ka talitluse katkemisvastane skeem.

Nagu juba aimata võis, ei kasuta me kettasalvestussüsteemi katkemisvastasuse tagamiseks RAID (Redundant array of independent Disks) kontseptsiooni, vaid RAIN (Redundant array of independent Nodes) kontsepti. See tähendab, et katkemisvastasust mõõdetakse, automatiseeritakse ja hallatakse sõlmedest, mitte ketastest. Kettad on kahtlemata salvestusobjektid, neid jälgitakse, ja nendega saab teha kõiki standardseid toiminguid, sealhulgas koguda kohalikku riistvaralist RAIDi, kuid klaster opereerib just sõlmedega.

Kui tekib tugev soov RAID-i järele (näiteks stsenaarium, mis toetab mitmeid rikkumisi väikestes klastrites), ei takista miski kasutada kohalikke RAID-kontrollereid ja nende peale luua hajutatud salvestuslahendust ning RAIN-architectuuri. Selline stsenaarium on täiesti realistlik ja meie poolt toetatud, seetõttu räägime sellest vAIR-i rakendusskeemide artiklis.

Salvestuslahenduse tõrketaluvuse skeemid

vAIR-i virtuaalsete ketaste tõrketaluvuse skeeme võib olla kahte tüüpi:

1) Replikatsioonifaktor ehk lihtsalt replikatsioon - see tõrketuksamise meetod on lihtne nagu „pulk ja nöör“. Käib sünkroonne replikatsioon node’ide vahel, kus faktor on 2 (2 koopiat klastri kohta) või 3 (3 koopiat, vastavalt). RF-2 võimaldab virtuaalsel kettal taluda ühe node'i rikke klastris, kuid „järelikult“ kasutab see ära poole kasulikust mahust, samas kui RF-3 talub kahe node'i rikke klastris, reservides juba 2/3 kasulikest mahudest oma vajaduste jaoks. See skeem sarnaneb väga RAID-1-le, st virtuaalplaat, mis on konfigureeritud RF-2-s, on kaitstud ükskõik millise ühe node'i rikke eest klastris. Sellisel juhul on andmetega kõik korras ja isegi sisendi-väljundi tegevus ei peatu. Kui rikutud node uuesti töökorda tuleb, algab automaatne andmete taastamine/sünkroonimine.

Allpool on toodud näited andmete jaotumisest RF-2 ja RF-3 töörežiimis ja tõrgete olukordades.

Meil on 8 MB suurune virtuaalne masin unikaalsete (kasutatavate) andmete osas, mis töötab neljal vAIR sõlmel. On selge, et reaalsuses ei pruugi selline väike maht olla, kuid ARDFS tööloogikat näitava skeemi jaoks on see näide kõige arusaadavam. AB – need on 4 MB suurused virtuaalsed plokid, mis sisaldavad virtuaalmasina unikaalseid andmeid. RF-2 puhul luuakse neist kaht koopiat, A1+A2 ja B1+B2. Need plokid „jaotatakse“ sõlmede vahel, vältides samade andmete kattumist ühes sõlmes, st koopia A1 ei ole sama sõlmes koos koopia A2-ga. B1 ja B2 puhul on sarnane põhimõte.

Kui üks sõlm, näiteks sõlm nr 3, kus asub koopia B1, ebaõnnestub, aktiveeritakse see koopia automaatselt sõlmes, kus pole koopia koopiat (st koopiat B2).

Seega suudavad virtuaalne ketas (ja VM) hõlpsasti taluda ühe sõlme, mis on välja lülitatud RF-2 skeemis.

Replitseerimise skeem, kuigi see on lihtne ja usaldusväärne, kannatab sama probleemi all nagu RAID1 – kasulikku ruumi on vähe.

2) Kustutuskoodimine ehk erasure coding (tuntud ka kui "ülearune koodimine", "kustutuskoodimine" või "ülearuse kood") on välja töötatud eespool mainitud probleemi lahendamiseks. EC on ülearuse skeem, mis tagab andmete kõrge kättesaadavuse madalamate kettaruumi kuludega võrreldes replikatsiooniga. Selle mehhanismi tööpõhimõte sarnaneb RAID 5, 6 ja 6P-iga.

Koodimise protsessis jagab EC virtuaalne blokk (vaikimisi 4MB) väiksemateks "andmeosadeks" vastavalt EC skeemile (näiteks skeem 2+1 jagab iga 4MB bloki kaheks 2MB tükiks). Seejärel genereerib protsess paranoiaosi suurusega mitte rohkem kui üks varem jagatud osa. Dekodeerimisel genereerib EC puuduvad tükid, lugedes "elusolevaid" andmeid üle kogu klastrite.

Näiteks virtuaalne ketas EC skeemiga 2 + 1, teostatud 4 klastrinodega, talub rahulikult ühe klastrinoodi rikke nagu ka RF-2 puhul. Siiski on kulud madalamad, nimelt kasuliku mahtude suhe RF-2 puhul on 2, samas kui EC 2+1 puhul on see 1,5.

Lihtsustatult öeldes jagatakse virtuaalne plokk 2-8 (miks 2 kuni 8 - seda vaata allpool) "tükiks", ja nendele tükkidele arvutatakse sarnase mahuga "tükid" pariteedi.

Lõpuks jaotatakse andmed ja pariteet ühtlaselt kogu klastrisse. Nagu ka replikatsiooni puhul, jagab ARDFS automaatselt andmed nodide vahel nii, et ei lubata sama andmete (andmete ja nende pariteedi koopiaid) hoidmist ühes nodis, et vältida andmete kaotamist juhul, kui andmed ja nende pariteet satuvad ootamatult samasse salvestusnodisse, mis ebaõnnestub.

Allpool on näide sama virtuaalmasinaga, mille maht on 8 MB ja 4 nodiga, kuid juba EC 2+1 skeemi puhul.

Moodulid A ja B jagunevad kaheks 2 MB tükiks (kasutades kahe asemel 2+1), see tähendab A1+A2 ja B1+B2. Erinevalt kopeerimisest, A1 ei ole A2 koopia, vaid virtuaalne A plokk, mis on jagatud kaheks osaks, sama kehtib ploki B kohta. Kokku on meil kaks komplekti 4 MB, milles igas on kaks kahemegabaidist tükki. Edasi, igas neist komplektidest arvutatakse pariteet, mille mahutavus on maksimaalselt üks tükk (st 2 MB), mis annab meile lisaks + 2 pariteedi tükki (A-P ja B-P). Kokku saame 4×2 andmeid + 2×2 pariteeti.

Seejärel jaotatakse tükid nodidesse nii, et andmed ei kattuks nende pariteediga. See tähendab, et A1 ja A2 ei paikne samas nodis A-P-ga.

Kui üks nodo, eeldame, et kolmas, ebaõnnestub, taastatakse rikutud plokk B1 automaatselt pariteedist B-P, mis on salvestatud nodo nr 2-s, ja aktiveeritakse nödol, kus ei ole B pariteeti, see tähendab tükki B-P. Antud näites on see nodo nr 1.

Olen kindel, et lugejal tekib küsimus:

«Kõik, mida te kirjeldasite, on juba ammu rakendatud konkurentide ja avatud lähtekoodiga lahendustes, mis teeb teie EC rakenduse ARDFS-is eriliseks?»

Edasi tulevad huvitavad omadused ARDFS-i toimimisest.

Erasure coding paindlikkusele keskendudes.

Alguses planeerisime üsna paindliku EC X+Y skeemi, kus X on vahemikus 2 kuni 8 ja Y vahemikus 1 kuni 8, kuid alati väiksem või võrdne X-iga. See skeem on mõeldud paindlikkuse tagamiseks. Virtuaalse ploki andmeosade (X) arvu suurendamine vähendab kulusid, see tähendab, et see suurendab kasulikku ruumi.
Parityosade (Y) arvu suurendamine suurendab virtuaalse ketta usaldusväärsust. Mida suurem on Y väärtus, seda rohkem sõlmi klastris võib ebaõnnestuda. Loomulikult vähendab pariteedi mahu suurendamine kasuliku mahutavuse suurust, kuid see on hind usaldusväärsuse eest.

Skeemide EC jõudlus sõltub peaaegu otseselt: mida rohkem on 'tükke', seda madalam on jõudlus, siin on ilmselge, et vajalik on tasakaalustatud lähenemine.

Selline lähenemine võimaldab administraatoritel maksimaalselt paindlikult konfigureerida jaotatud salvestust. ARDFS-i partii raames saab kasutada mis tahes tõrkekindluse skeeme ja nende kombinatsioone, mis on meie arvates samuti väga kasulik.

Allpool on toodud mitme (mitte kõikide võimalike) RF ja EC skeemide võrdlustabel.

Tabelist on näha, et isegi kõige "rikkam" EC 8+7 kombinatsioon, mis lubab klastris samal ajal kaotada kuni 7 sõlme, võtab vähem kasulikku ruumi (1,875 versus 2) kui standardne replikatsioon, ja kaitseb 7 korda paremini. See muudab selle kaitsemehhanismi, ehkki keerulisema, siiski palju atraktiivsemaks olukordades, kus tuleb tagada maksimaalne usaldusväärsus piiratud kettaruumi tingimustes. Samas tuleb mõista, et iga „pluss“ X või Y juurde tähendab täiendavaid tootmiskulusid, seega tuleb usaldusväärsuse, säästmise ja tootlikkuse vahelises kolmnurgas teha valikud väga ettevaatlikult. Sel põhjusel pühendame eraldi artikli eemaldava kodeerimise suurendamisele.

Failisüsteemi usaldusväärsus ja iseseisvus

ARDFS töötab kõigis klastrite nodedes lokaalselt ja sünkroniseerib neid omaette vahenditega kaudu eraldatud Etherneti liideste. Oluline aspekt on see, et ARDFS sünkroniseerib mitte ainult andmeid, vaid ka salvestamisega seotud metaandmeid. ARDFS-i arendamise käigus uurisime paralleelselt mitmeid olemasolevaid lahendusi ja avastasime, et paljud teevad failisüsteemi metaandmete sünkroniseerimist välise jaotatud andmebaasihalduriga, mida kasutame ka sünkroniseerimiseks, kuid ainult konfiguratsioonide, mitte failisüsteemi metaandmete jaoks (sellest ja teistest seotud alamsüsteemidest tuleb järgmises artiklis).

Failisüsteemi metaandmete sünkroniseerimine välise andmebaasihalduriga on loomulikult toimiv lahendus, kuid siis sõltuks ARDFS-is salvestatud andmete järjepidevus välisest andmebaasihaldurist ja selle käitumisest (ja see on otsekui üsnagi kapriisne daam), mis meie arvates pole hea. Miks? Kui failisüsteemi metaandmed saavad kahjustada, siis saab ka failisüsteemi enda andmetele öelda "head aega", mistõttu otsustasime minna keerukamat, kuid usaldusväärsemat teed.

ARDFS-i metaandmete sünkroonimise alamsüsteemi lõime me ise ning see toimib täiesti iseseisvalt kõrvalasuvate alamsüsteemide suhtes. See tähendab, et ükski teine alamsüsteem ei saa ARDFS-i andmeid kahjustada. Meie arvates on see kõige usaldusväärsem ja õigem tee; kas see tõesti nii on, näitab aeg. Lisaks toob selline lähenemine kaasa ka täiendava eelise. ARDFS-i saab kasutada iseseisvalt vAIR-ist, lihtsalt kui laienenud salvestusruumina, mida me kindlasti kasutanud oleme tulevastes toodetes.

Kokkuvõttes, arendades ARDFS-i, saime paindliku ja usaldusväärse failisüsteemi, mis annab valiku, kus saab salvestusmahult kokku hoida või andmeid optimeerida, või teha salvestus ruumi ülimalt usaldusväärseks mõistliku hinna eest, kuid vähendades nõudmisi jõudlusele.

Koos lihtsa litsentsipoliitika ja paindliku tarnemudeliga (tulevikku vaadates, litsentseeritakse vAIR sõlmedena ning tarnitakse kas tarkvarana või kui PAK) võimaldab see täpselt kohandada lahendust erinevatele klientide nõudmistele ning hiljem kergesti seda tasakaalu hoida.

Kellele see ime vajalik on?

Ühest küljest võib öelda, et turul on juba mängijad, kellel on tõsised hüperkonvergeeritud lahendused, ja kuhu me tegelikult siseneme. See väide tundub tõene, KUID...

Teisest küljest, kui minna "välja ja põllule" ning vestelda klientidega, näeme meie ja meie partnerid, et asi ei ole sugugi nii. Hüperkonvergeeritud lahendusi vajavaid probleeme on palju: mõnes kohas ei teata, et sellised lahendused eksisteerivad, mõnes kohas tunduvad need liiga kallid, mõnes kohas on alternatiivsete lahenduste testid ebaõnnestunud, ja mõnes kohas on ostmisele lihtsalt keeld, sest sanktsioonid. Ühesõnaga, põld on osutunud harimatuks, seetõttu läksime me seda harima))).

Millal on SÜD parem kui GKS?

Turuga töötades küsitakse meid sageli, millal on parem rakendada klassikalist skeemi SÜD-ga ja millal - hüperkonvergeerumisega? Paljud GKS-i tootmisettevõtted (eriti need, kellel portfellis ei ole SÜD-d) ütlevad: „SÜD on oma aja elanud, hüperkonvergeerumine ainult!“. See on julge väide, kuid ei peegelda olukorda täiesti õigesti.

Tõtt-öelda liigub SÜD turg tõeliselt hüperkonvergeeritud ja sarnaste lahenduste suunas, kuid alati on olemas „aga“.

Esiteks, klassikalise jaotusega andmekeskused ja IT-infrastruktuurid ei saa lihtsalt niisama ümber ehitada, seega selliste infrastruktuuride moderniseerimine ja täiendamine on pärand, mis kestab veel 5-7 aastat.

Teiseks, need infrastruktuurid, mis praegu massiliselt ehitatakse (peamine fookus Venemaale), rajatakse klassikalise skeemi järgi, kasutades jaotatud salvestust, mitte seetõttu, et inimesed ei tea hüperkonvergentsist, vaid seetõttu, et hüperkonvergendi turg on uus, lahendused ja standardid pole veel kindlaks kujunenud, IT-spetsialiste pole veel koolitatud, kogemust on vähe, ja andmekeskusi tuleb ehitada siin ja praegu. See suundumus jätkub veel 3-5 aastat (ja siis tuleb veel pärand, vt punkt 1).

Kolmandaks, on puhas tehniline piirang, et kirjutamise lisaviivitused on 2 millisekundit (ilma kohalikku vahemälu arvesse võtmata, muidugi), mis on hind jaotatud salvestamise eest.

Ja ärgem unustagem suurte füüsiliste serverite kasutamist, mis eelistavad vertikaalset salvestusmahtu.

On palju vajalikke ja populaarseid ülesandeid, kus SSi toimib paremini kui HSi. Loomulikult ei nõustu meiega need tootjad, kelle tooteportfellis pole SSi, kuid me oleme valmis veenvalt arutlema. Loodetavasti, kui me, nagu nende kahe toote arendajad, tulevikus avaldame võrdluse SSI ja HSi vahel, näitame selgelt, millistes tingimustes kumb on parem.

Kus siis hüperkonvergeeritud lahendused töötavad paremini kui SSI?

Ülaltoodud teesidest lähtuvalt saab teha kolm ilmselget järeldust:

Seal, kus täiendavad 2 millisekundit viivitust kirjutamisel, mis püsivalt tekib igas tootmises (praegu ei räägi me sünteetilisest, sünteetikas võib ka nanosekundeid näidata), ei ole kriitilised, sobib hüperkonvergeeritud lahendus.
Seal, kus koormus suurtest füüsilistest serveritest saab muuta paljude väikeste virtuaalsete hulka ja jaotada nodide vahel, sobib hüperkonvergeeritud lahendus samuti suurepäraselt.
Seal, kus horisontaalne skaleerimine on prioriteediks kõrgem kui vertikaalne, sealgi sobivad HSi suurepäraselt.

Mis need lahendused on?

Kõik standardsed infrastruktuuri teenused (katalooge teenus, e-post, ESM, failiserverid, väikesed või keskmised ERP ja BI süsteemid jne). Me nimetame seda 'üldiseks arvutamiseks'.
Pilveteenuste infrastruktuur, kus on vajalik kiiresti ja standardiseeritult horisontaalset skaleerimist ning lihtsasti suurt hulka virtuaalmasinaid klientide jaoks 'jaotades'.
Infrastruktuur virtuaalsed töölaudade (VDI), kus palju väikeseid kasutaja virtuaalmasinaid käivitatakse ja rahulikult 'ujuvad' ühesuguses klastris.
Filiaalivõrgud, kus igas filiaalis on vaja standardset, tõrkekindlat, kuid samas odavat infrastruktuuri 15-20 virtuaalmasinaga.
Igakülgsed jaotatud arvutused (big data teenused, näiteks). Seal, kus koormus ei liigu 'sügavusele', vaid 'laiusele'.
Testkeskkonnad, kus on lubatud lisaviivitused, kuid on eelarve piirangud, kuna tegemist on testidega.

Praegu oleme just nende ülesannete jaoks loonud AERODISK vAIR ja suuname tähelepanu neile (praegu edukalt). Võib-olla muutub see peagi, kuna maailm ei seisa paigal.