🥇Hüperkonvergeeritud lahendus AERODISK vAIR. Alus - failisüsteem ARDFS

Tere, Habra lugejad. Selle artikli kaudu avame tsükli, mis räägib meie loodud hüperkonvergentse süsteemist AERODISK vAIR. Alguses soovisime esimeses artiklis rääkida kõigest, kuid süsteem on üsna keeruline, seega võtame selle ette osade kaupa.

Alustame süsteemi loomise ajaloost, sukeldume ARDFS failisüsteemi, mis on vAIRi alus, ja arutame veidi ka selle lahenduse positsioneerimist Venemaa turul.

Tulevastes artiklites räägime lähemalt erinevatest arhitektuurilisest komponentidest (kluster, hüperviisor, koormuse tasakaalustaja, jälgimissüsteem jne), seadistamisprotsessist, tõstatame litsentsimise küsimused, näitame eraldi kokkuvarisemiskatse läbi ja loomulikult kirjutame koormustestimisest ja suurendamisest. Samuti pühendame eraldi artikli vAIRi community-versioonile.

AERODISK on kui lugu andmehoidlatest? Või miks me üldse hüperkonvergentsiga tegelema hakkasime?

Algne idee luua oma hüperkonvergent tekkis meil kuskil 2010. aasta paiku. Sel ajal ei olnud ei AERODISK ega sarnaseid lahendusi (kommertslikud kastisüsteemid) turul. Meie ülesanne oli järgmine: serverite komplekt, millel on kohalike ketaste ühendamine Etherneti protokolli kaudu, tuli muuta hajutatud salvestuseks ning sealjuures jooksutada virtuaalmasinaid ja tarkvara võrku. Kõik see pidi toimuma ilma andmehoidlate süsteemideta (sest andmehoidlate süsteemi ja selle tarvikute jaoks polnud lihtsalt raha, ja oma andmehoidlat me siis veel ei leiutanud).

Proovisime palju avatud lähtekoodiga lahendusi, kuid lahendasime selle ülesande, kuigi lahendus oli väga keeruline ning seda oli raske korrata. Pealegi oli see lahendus pigem selline „Kas see töötab? Ära vaata!” Seetõttu, kui selle ülesande lahendasime, ei hakanud me enam edasi arendama ideed, et meie töö tulemus muuta täielikuks tooteks.

Pärast seda juhtumit jätsime selle idee kõrvale, kuid tunne, et see ülesanne on täiesti lahendatav ja selle lahenduse kasu on rohkem kui ilmne, ei jätnud meid. Edasi tulid väliskompaniide välja toodud HCI-tooted, mis ainult kinnitasid seda tunnet.

Seetõttu naasisime 2016. aasta keskel selle ülesande juurde, luues täieõiguslikku toodet. Siis puudusid meil igasugused suhted investoritega, seega pidime arendusstandardi ostma oma väheste rahade eest. Ostes Avitost kasutatud servereid ja lüliteid, asusime tööle.

Peamine algne ülesanne oli luua oma, kuigi lihtne, failisüsteem, mis suudaks automaatselt ja ühtlaselt jaotada andmeid virtuaalsete plokkidena klastrisse kuuluvatesse n-isse sõlmedesse, mis on ühendatud Ethernet'i kaudu. Samal ajal peab failisüsteem hästi ja lihtsalt skaleeruma ning olema sõltumatu külgnevate süsteemide, st olema isoleeritud vAIR-i poolest kui "lihtsalt salvesti".

Esimene vAIR kontseptsioon

Otsustasime teadlikult loobuda valmis open source lahenduste kasutamisest hajutatud salvestuse korraldamiseks (ceph, gluster, lustre ja sarnased) oma arenduse kasuks, kuna meil oli nendega juba palju projektikogemust. Ilmselt on need lahendused iseenesest suurepärased ja enne Aerodiski töötamist oleme nendega realiseerinud rohkem kui ühe integratsiooniprojekti. Kuid ühe ettevõtja konkreetse ülesande täitmine, personali koolitamine ja suure müügi toetuse ostmine on üks asi, samas kui lihtsalt reprodutseeritava toote loomine, mida kasutatakse erinevate ülesannete jaoks, millest me kui müüja võib-olla isegi ise ei tea, on hoopis teine asi. Seetõttu ei sobinud meile olemasolevad open source tooted teise eesmärgi saavutamiseks ja otsustasime luua hajutatud failisüsteemi ise.
Kaks aastat hiljem saavutas väheste arendajate agiteerimisega (kes olid kombineerinud vAIR-i arendust klassikalise andmesalvestusülesande Engine'i arendamisega) teatud tulemuse.

2018. aastaks olime kirjutanud kõige lihtsama failisüsteemi ning täiendanud selle vajaliku raamistiku. Süsteem ühendas siseinterneti kaudu erinevatelt serveritelt füüsilised (kohalikud) kettad üheks tasaseks basseiniks ning "lõikas" need virtuaalseteks plokkideks; seejärel loodi virtuaalsetest plokkidest plokiseadmed, millel oli teatud raskusastme taluvus ja mille peal loodi ja käidi virtuaalmasinad KVM hüperviisori abil.

Me ei hakanud failisüsteemi nime üle palju muretsema ja nimetasime selle lakooniliselt ARDFS-iks (arva, mida see tähendab))

See prototüüp nägi hea välja (visuaalselt, muidugi, visuaalne kujundus polnud siis veel olemas) ja näitas häid tulemusi jõudluse ja skaleeritavuse osas. Pärast esimest reaalselt saavutatud tulemust andsime sellele projektile edasi, korraldades tõelise arenduskeskkonna ning eraldi meeskonna, mis töötas ainult vAIR-i kallal.

Just sellisel ajal valmistasime ette lahenduse üldise arhitektuuri, mis ei ole siiani tõsiseid muudatusi kogenud.

Sukeldume failisüsteemi ARDFS

ARDFS on vAIR-i alus, mis tagab kogu klastrite jaotatud tõrketaluvuse andmete salvestamise. Üks (aga mitte ainus) ARDFS-i silmapaistvamaid omadusi on see, et see ei kasuta mingeid lisandeid pühendatud serveritele meta ja haldamise jaoks. Nii oli algselt plaanitud lahenduse konfigureerimise lihtsustamiseks ja usaldusväärsuse tagamiseks.

Salvestamise struktuur

Kogu klastrite node’de raames organiseerib ARDFS loogilise basseini kogu saadaval olevast kettaruumist. On oluline mõista, et bassein ei ole veel andmed ja mitte formaaditud ruum, vaid lihtsalt joonistus, st kõik node’d, kus on installitud vAIR, lisatakse automaatselt ARDFS-i ühisesse basseini ja kettaressursid muutuvad automaatselt kõigis klastrites jagatavaks (ja tulevaste andmete salvestamiseks kergesti kättesaadavaks). Selline lähenemine võimaldab kiiresti lisada ja eemaldada node’sid ilma tõsise mõjuta juba töötavale süsteemile. See tähendab, et süsteemi on väga lihtne skaleerida „tellistega“, lisades või eemaldades node’e klastris vastavalt vajadusele.

ARDFS-i basseini peale lisatakse virtuaalsed kettad (salvestusobjektid virtuaalmasinate jaoks), mis on loodud 4 megabaidi suurustest virtuaalsetest blokidest. Virtuaalsetes kettas hoitakse otseselt andmeid. Virtuaalsete kettaste tasandil määratakse samuti välja tõrketaluvuse skeem.

Nagu juba võis arvata, ei kasuta me kettasüsteemi tõrke taluvuse tagamiseks RAID-i (Redundant array of independent Disks) kontseptsiooni, vaid RAIN-i (Redundant array of independent Nodes). St. tõrke taluvus mõõdetakse, automatiseeritakse ja hallatakse sõlmedest, mitte ketastest. Kettad on loomulikult ka salvestusobjekt, neid jälgitakse nagu kõike muud, nendega saab teha kõiki tavapäraseid toiminguid, sealhulgas koguda kohalikku riistvara RAID-i, kuid klaster opereerib just nimelt sõlmedega.

Kui olukord on selline, et väga soovitakse RAID-i (näiteks stsenaarium, mis toetab mitmeid rikkeid väikestes klastrites), ei takista miski kasutada kohalikke RAID-kontrollereid, ning nende peale luua venitatud salvestus ja RAIN-architektuur. Selline stsenaarium on täiesti elujõuline ja selle toetamine, mistõttu räägime sellest vAIR-i tüüpiliste rakenduste stsenaariumide artiklis.

Salvestussüsteemi tõrke taluvuse skeemid

vAIR-i virtuaalsete kettaste tõrke taluvuse skeeme võib olla kahte tüüpi:

1) Replikatsioonifaktori või lihtsalt replikatsiooni meetod, mis on tõrke taluvuse meetod, mis on sama lihtne kui „puu ja nöör“. Sõlmede vahel toimub sünkroonne replikatsioon 2:1 (2 koopiat klastris) või 3:1 (3 koopiat, vastavalt). RF-2 võimaldab virtuaalsel kettal taluda ühe sõlme riket klastris, kuid „kulutab“ poole kasulikust mahust, samas kui RF-3 talub 2 sõlme riket klastris, kuid reserveerib juba 2/3 kasulikust mahust oma vajaduste katmiseks. See skeem sarnaneb väga RAID-1-le, st virtuaalne kettas, mis on konfigureeritud RF-2, on rikke suhtes talutav mistahes üksikule sõlmele klastris. Sel juhul on andmetega kõik korras ja isegi sisse-/väljaandmine ei peatu. Kui langenud sõlm tagasi tööle tuleb, algab automaatne taastamine/sünkroniseerimine andmetega.

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

Meil on 8 MB ainulaadse (kasutaja) andmemahu virtuaalmasin, mis töötab 4 vAIR nodi peal. On selge, et reaalsuses on selline väike maht ebatõenäoline, kuid see näide illustreerib ARDFS-i töölogikat kõige paremini. AB – need on 4 MB virtuaalsed plokid, mis sisaldavad virtuaalmasina ainulaadset teavet. RF-2 puhul luuakse nendest plokkidest kaks kopeerimist, A1+A2 ja B1+B2, vastavalt. Need plokid jaotatakse nodide vahel, vältides sama teabe kattumist ühes nodis, st koopia A1 ei asu ühes nodis koos koopia A2-ga. B1 ja B2 puhul on analoogne lähenemine.

Kui üks nodidest (näiteks nod №3, kus asub B1 koopia) tõrkub, aktiveeritakse see koopia automaatselt nodis, kus ei ole tema koopia kopeerimist (st koopia B2).

Nii on virtuaaldisk (ja vastavalt ka VM) lihtsasti vastupidav ühe nodi tõrkele RF-2 skeeme kasutades.

Replikatsiooniskeem, hoolimata oma lihtsusest ja usaldusväärsusest, kannatab sama probleemi all nagu RAID1 – vähe kasulikku ruumi.

2) Erasure coding ehk kustutuskoodimine (tuntud ka kui 'liigne koodimine', 'kustutuskood' või 'ülejäänud kood') eksisteerib selle probleemi lahendamiseks. EC – see on ülejäägiskeem, mis tagab andmete kõrge kättesaadavuse väiksemate kuludega võrreldes replikatsiooniga. Selle mehhanismi tööpõhimõte sarnaneb RAID 5, 6, 6P-ga.

Koodimise protsess EC jagab virtuaalse ploki (vaikimisi 4 MB) mitmeks väiksemaks 'andmeplokiks' sõltuvalt EC skeemist (näiteks skeem 2+1 jagab iga 4 MB ploki 2 osaks 2 MB). Seejärel genereerib see protsess 'pariteedi plokid', mis ei ületa eelnevalt jagatud osade suurust. Dekodeerimisel genereerib EC puuduolevad osad, lugedes 'ellujäänud' andmeid kogu klastrist.

Näiteks virtuaaldisk EC skeemiga 2+1, mis on rakendatud 4 nodiga klastris, talub rahulikult ühe nodi tõrget klastris samal viisil nagu RF-2. Sel juhul on kulud madalamad, näiteks RF-2 efektiivsuse koefitsient on 2, samas kui EC 2+1 puhul on see 1,5.

Lihtsamalt öeldes on idee selles, et virtuaalne plokk jagatakse 2-8 osaks (miks 2-st 8-ni, vt allpool), ja nendele osadele arvutatakse sama suurusega 'pariteedi' osad.

Lõpuks jagatakse andmed ja pariteet võrdselt kõikide klastrinode vahel. Nagu ka replikatsiooni puhul, jagab ARDFS automaatselt andmeid nodide vahel nii, et ei lubataks samaaegset identsete andmete (andmete koopiaid ja nende pariteeti) säilitamist ühel nodil, et minimeerida võimalust andmete kaotamiseks, juhul kui andmed ja nende pariteet satuvad ühel salvestusnodule kokku, mis ebaõnnestub.

Allpool on näide sama virtuaalmasinaga, mille RAM on 8 MB ja nelja nodiga, kuid nüüd EC skeemiga 2+1.

Plokid A ja B jagatakse kaheks tükiks, igaühe suurus on 2 MB (kahte tükki, kuna 2+1), st A1+A2 ja B1+B2. Erinevalt replikatsioonist ei ole A1 A2 koopia, see on virtuaalne plokk A, mis on jagatud kaheks osaks, samuti on plokk B. Kokku tekib meil kaks komplekti, mille igas on 4 MB ja milles on kaks kahte megabaidist tükki. Järgmiseks arvutame nende komplektide jaoks pariteedi, mille maht on mitte rohkem kui üks tükk (st 2 MB), saame veel 2 tükki pariteeti (A-P ja B-P). Kokku on meil 4×2 andmeid + 2×2 pariteeti.

Seejärel jaotatakse tükid nodide vahel nii, et andmed ei jääks nende pariteediga kokku. St A1 ja A2 ei paikne samal nodil koos A-P-ga.

Ühe nodi (ütleme, et sama kolmas) tõrke korral taastatakse ebaõnnestunud plokk B1 automaatselt pariteedist B-P, mis asub nodil nr 2, ja aktiveeritakse nodil, kus ei ole B-pariteeti, st tükk B-P. Selles näites on see nodi 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 on teie ARDFS EC rakenduse erinevus?“

Edasi tulevad huvitavad omadused ARDFS tööprotsessis.

Kustutuskood, millel on paindlikkuse rõhk

Alguses planeerisime üsna paindliku EC skeemi X+Y, 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 ette nähtud paindlikkuse saavutamiseks. Andmete tükkide arvu (X) suurendamine, millesse virtuaalne plokk jagatakse, vähendab ülehead, st suurendab kasulikku ruumi.
Pariteedi tükkide arvu (Y) suurendamine suurendab virtuaalse ketta usaldusväärsust. Mida suurem on Y väärtus, seda rohkem node klastris võib ebaõnnestuda. Loomulikult vähendab pariteedi mahu suurendamine kasulikku mahtu, kuid see on tasu usaldusväärsuse eest.

Tootlikkuse sõltuvus EC skeemidest on peaaegu sirge: mida rohkem "tükke", seda madalam on tootlikkus, siin on vajalik tasakaalustatud lähenemine.

See lähenemine võimaldab administraatoritel võimalikult paindlikult konfigureerida venitatud salvestust. ARDFS-i all olevas bassein on võimalik kasutada igasuguseid talitlushäirete kritiseerimise skeeme ja nende kombinatsioone, mis on samuti meie arvates väga kasulik.

Allpool on toodud võrdlustabel mitmete (mitte kõigi võimalike) RF ja EC skeemide kohta.

Tabelist on näha, et isegi kõige "karmim" EC 8+7 kombinatsioon, mis lubab samal ajal kaotada kuni 7 sõlme klastris, "neelab" vähem kasulikku ruumi (1,875 võrreldes 2) kui standardne replikatsioon, ja kaitseb 7 korda paremini, mistõttu on see kaitsetehnika kuigi keeruline, kuid oluliselt atraktiivsem olukordades, kus on vaja tagada maksimaalset usaldusväärsust piiratud kettaruumi tingimustes. Samuti tuleb mõista, et iga "pluss" X või Y juures tähendab täiendavaid toimetusi tootlikkusele, seega tuleb kolmnurgas usaldusväärsuse, säästmise ja tootlikkuse vahel hoolikalt valida. Just seetõttu pühendame eraldi artikli kaugseadmise kodeerimise mõõtmisele.

Failisüsteemi usaldusväärsus ja autonoomia

ARDFS käivitatakse kohapeal kõigis klastris olevates sõlmedes ja sünkroniseerib neid oma vahenditega läbi eraldatud Ethernet-liideste. Oluline on see, et ARDFS sünkroniseerib iseseisvalt mitte ainult andmeid, vaid ka andmete salvestamisega seotud metaandmeid. ARDFS-i arendamise käigus uurisime paralleelselt mitmeid olemasolevaid lahendusi ja avastasime, et paljuski sünkroniseerivad nad failisüsteemi metaandmeid väliste jaotatud andmebaaside kaudu, mida kasutame ka sünkroniseerimiseks, kuid ainult seadistuste, mitte failisüsteemi metaandmete osas (sellest ja teistest seotud alamsüsteemidest järgmises artiklis).

Metaandmete sünkroniseerimine failisüsteemi koos välise andmebaasihalduriga on küll toimiv lahendus, kuid siis sõltuks ARDFS-is hoitavate andmete järjepidevus välisest andmebaasihaldurist ning selle käitumisest (mis, tuleb tõdeda, on kapriisilne), mis meie arvates on halb. Miks? Kui failisüsteemi metainformatsioon kahjustub, võivad ka failisüsteemi andmed öelda "head aega", seega otsustasime minna keerulisemat, kuid usaldusväärsemat teed.

Meie lõime ARDFS-i jaoks metainformatsiooni sünkroniseerimise alamsüsteemi iseseisvalt ning see toimib täielikult sõltumatult külgnevate alamsüsteemide tegevusest. 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, kuid kas see on tõesti nii, näitab aeg. Lisaks, sellise lähenemisega tekib täiendav eelis. ARDFS-i saab kasutada iseseisvalt vAIR-st, lihtsalt kui laialt levinud andmesalvestust, millega me kindlasti tulevastes toodetes edasi kasutame.

Sellega, et oleme ARDFS-i välja töötanud, oleme saanud paindliku ja usaldusväärse failisüsteemi, mis pakub valikut, kus saab vähendada mahtu või panustada kõike jõudlusse, või teha salvestusruum ülialti usaldusväärseks mõõduka hinna eest, kuid vähendades jõudlusnõudeid.

Koos lihtsa litsentsimise poliitika ja paindliku tarnemudeliga (enne välja öeldes, litsentsitakse vAIR sõlmede järgi ja tarnitakse kas tarkvarana või PAK-ina) võimaldab see lahendust täpselt kohandada erinevate klientide nõudmistega ja hiljem seda tasakaalu lihtsalt säilitada.

Kellele seda imet vaja on?

Ühelt poolt võib öelda, et turul on juba mängijaid, kellel on tõsised lahendused hüperkonvergeeritud valdkonnas, kuhu me siis sisuliselt tungime. Tundub, et see väide on õige, KUID…

Teiselt poolt, minnes "välja lõpudesse" ja suheldes klientidega, näeme meie ja meie partnerid, et asi pole sugugi nii. Hüperkonvergeeritud lahenduste jaoks on palju ülesandeid, kus inimesed ei teadnud lihtsalt, et selliseid lahendusi on olemas, kus see tundus kallis, kus alternatiivsete lahenduste testimine läks kehvasti, ja kus pidavad isegi ostmist keelduma, kuna sanktsioonid. Ühesõnaga, väli osutus harimata maaks, seega läksime seda üles tõstma))).

Millal on andmesalvestus parem kui hüperkonvergeeritud süsteem?

Töötades turuga küsitakse meid sageli, millal on parem kasutada klassikalist skeemi SAN-iga ja millal hüperkonvergeerivaid lahendusi? Paljud ettevõtted, kes toodavad hüperkonvergeeritud lahendusi (eriti need, kelle portfellis ei ole SAN-e), ütlevad: "SAN on oma aja üle elanud, ainult hüperkonvergeeritud!" See on julge väide, kuid see ei peegelda täielikult reaalsust.

Tõde on see, et SAN-turg tõepoolest liigub hüperkonvergeerivate ja sarnaste lahenduste suunas, kuid alati on olemas "aga".

Esiteks, rajatud andmekeskuseid ja IT-infrastruktuure klassikalise skeemi alusel SAN-iga ei saa niisama lihtsalt ümber ehitada, seega nende infrastruktuuride moderniseerimine ja täiendamine on veel 5–7 aastat kestnud pärand.

Teiseks, enamiku infrastruktuuride, mis praegu rajatakse (silmas peetakse Venemaad), aluseks on klassikaline skeem SAN-iga. Ja mitte sellepärast, et inimesed ei tea hüperkonvergeeritest, vaid kuna hüperkonvergeeritud turg on uus, lahendused ja standardid ei ole veel paika loksunud, IT-spetsialistid pole veel koolitatud, kogemusi on vähe ja andmekeskuseid tuleb rajada siin ja nüüd. See tendents kestab veel 3–5 aastat (ja siis jääb jälle pärand, vt punkt 1).

Kolmandaks, puhas tehniline piirang väikeste 2 millisekundiliste viivitustega kirjutamisel (loomulikult, arvestamata kohalike vahemälusid), mis on hind jagatud salvestuse eest.

Ja ärgem unustagem suurte füüsiliste serverite kasutamist, mis eelistavad vertikaalselt skaleerimist diskisüsteemi.

On palju vajalikke ja populaarseid ülesandeid, kus SAN käitub paremini kui hüperkonvergeeritud lahendused. Meiga ei nõustu kindlasti need tootjad, kelle tooteportfellis ei ole SAN-e, kuid oleme valmis põhjalikult vaidlema. Loomulikult, kui mõlemaid tooteid arendavad, teeme ühel tulevasest avaldamisest kindlasti SAN-i ja hüperkonvergeeritud lahenduste võrdluse, kus selgelt näitame, millistes tingimustes on kumbki parem.

Kus hüperkonvergeeritud lahendused töötavad SAN-ist paremini?

Eelnevate punktide põhjal saab teha kolm ilmset järeldust:

Kohas, kus täiendavad 2 millisekundilised viivitused kirjutamisel, mis tekivad igas tootmisprotsessis (praegu ei räägi me sünteetilistest katsetest, sünteetiliste testide puhul on võimalik näidata ka nanosekundeid), on mitte kriitilised, sobib hüperkonvergeeritud lahendus.
Seal, kus füüsiliste serverite koormust on võimalik muuta paljude väikeste virtuaalsete serverite vahel ja jagada seda node’ide vahel, sinna sobib hüperkonvergeeritud lahendus hästi.
Seal, kus horisontaalne skaleerimine on olulisem kui vertikaalne, sobivad GKS suurepäraselt.

Millised need lahendused on?

Kõik standard infrastruktuuri teenused (kataloogiteenused, e-post, dokumendihaldus, failiserverid, väikesed või keskmised ERP ja BI süsteemid jne). Me nimetame seda "üldised arvutused".
Kliendipoolsete infrastruktuuride jaoks, kus on vajalik kiire ja standardiseeritud horisontaalne laienemine ning lihtne suure arvu virtuaalmasinate loomine.
Infrastruktuur virtuaalsetele töölauale (VDI), kus käivitatakse palju väikeseid kasutajate virtuaalmasinaid, mis ujuvad ühtlases klastris.
Filiaalide võrgud, kus igas filiaalis on vaja standardset, talitlushäirete kindlat, kuid samas odavat infrastruktuuri 15-20 virtuaalmasina jaoks.
Igasugused jaotatud arvutused (nt big data teenused). Seal, kus koormus ei liberaalse välja, vaid laieneb.
Testimiskeskkonnad, kus on lubatud väiksed viivitused, kuid on eelarvepiirangud, kuna need on testid.

Praegusel hetkel oleme just nende ülesannete jaoks välja töötanud AERODISK vAIR ja keskendume neile (kuni praeguse edukuseni). Võib-olla see peagi muutub, kuna maailm ei seisa paigal.