Tere, Habri lugejad. Selle artikliga avame sarja, mis räägib meie väljatöötatud hüperkonvergeeritud süsteemist AERODISK VAIR. Algselt tahtsime esimeses artiklis kõike rääkida, kuid süsteem on üsna keeruline, nii et sööme elevanti osade kaupa.
Alustame lugu süsteemi loomise ajalooga, süveneme vAIR-i aluseks olevasse failisüsteemi ARDFS ning räägime veidi ka selle lahenduse positsioneerimisest Venemaa turul.
Edaspidistes artiklites räägime lähemalt erinevatest arhitektuurikomponentidest (klaster, hüperviisor, koormuse tasakaalustaja, monitooringusüsteem jne), konfiguratsiooniprotsessist, tõstatame litsentsiküsimused, näitame eraldi kokkupõrketestid ja loomulikult kirjutame koormustestimisest ja suuruse määramine. Samuti pühendame eraldi artikli vAIRi kogukonnaversioonile.
Kas Aerodisk on lugu salvestussüsteemidest? Või miks me üldse hüperkonvergentsi tegema hakkasime?
Algselt tekkis meil idee luua oma hüperkonvergents kuskil 2010. aasta paiku. Sel ajal ei olnud turul ei Aerodiski ega sarnaseid lahendusi (kaubanduslikud kastiga hüperkonvergeeritud süsteemid). Meie ülesanne oli järgmine: kohalike ketastega serverite komplektist, mida ühendas Etherneti protokolli kaudu ühendus, oli vaja luua laiendatud salvestusruum ning käivitada seal virtuaalmasinad ja tarkvaravõrk. Kõik see tuli realiseerida ilma salvestussüsteemideta (sest salvestussüsteemide ja selle riistvara jaoks lihtsalt polnud raha ning me polnud veel oma salvestussüsteeme leiutanud).
Proovisime paljusid avatud lähtekoodiga lahendusi ja lõpuks lahendasime selle probleemi, kuid lahendus oli väga keeruline ja raskesti korratav. Pealegi oli see lahendus kategoorias "Kas see töötab? Ärge puudutage! Seetõttu, pärast selle probleemi lahendamist, ei arendanud me edasi ideed muuta oma töö tulemus täisväärtuslikuks tooteks.
Pärast seda juhtumit eemaldusime sellest ideest, kuid siiski oli tunne, et see probleem on täielikult lahendatav ja sellise lahenduse eelised olid enam kui ilmsed. Hiljem välismaiste ettevõtete HCI tooted ainult kinnitasid seda tunnet.
Seetõttu pöördusime 2016. aasta keskel tagasi selle ülesande juurde täisväärtusliku toote loomise osana. Sel ajal meil veel investoritega suhteid ei olnud, mistõttu pidime arendusstendi ostma enda mitte väga suure raha eest. Olles kogunud kasutatud serverid ja Avito lülitid, asusime asja kallale.
Põhiline lähteülesanne oli luua oma, kuigi lihtne, kuid oma failisüsteem, mis saaks automaatselt ja ühtlaselt jaotada andmeid virtuaalplokkide kujul n-ndal arvul klastri sõlmedel, mis on Etherneti kaudu omavahel ühendatud. Samas peaks FS hästi ja lihtsalt skaleerima ning olema külgnevatest süsteemidest sõltumatu, s.t. võõranduda vAIR-ist "lihtsalt hoidla" kujul.
Esimene vAIR-i kontseptsioon
Loobusime sihilikult valmis avatud lähtekoodiga lahenduste kasutamisest venitatud ladustamise korraldamisel (tseph, gluster, luster jms) enda arengu kasuks, kuna meil oli nendega juba palju projektikogemust. Loomulikult on need lahendused iseenesest suurepärased ja enne Aerodiskiga töötamist rakendasime nendega rohkem kui ühe integratsiooniprojekti. Kuid üks asi on ühe kliendi jaoks konkreetse ülesande elluviimine, personali koolitamine ja võib-olla suure müüja toe ostmine, ja hoopis teine asi on luua hõlpsasti kopeeritav toode, mida kasutatakse erinevate ülesannete jaoks, mida me müüja, võib-olla me isegi ei tea enda kohta. Teiseks ei sobinud meile olemasolevad avatud lähtekoodiga tooted, mistõttu otsustasime ise hajutatud failisüsteemi luua.
Kaks aastat hiljem saavutasid mitmed arendajad (kes ühendasid vAIR-i töö klassikalise mootorisalvestussüsteemiga) teatud tulemuse.
2018. aastaks olime valmis kirjutanud lihtsa failisüsteemi ja täiendanud seda vajaliku riistvaraga. Süsteem ühendas erinevate serverite füüsilised (kohalikud) kettad sisemise ühenduse kaudu ühte lamedasse basseini ja “lõigas” need virtuaalseteks plokkideks, seejärel loodi virtuaalplokkidest erineva tõrketaluvusega plokkseadmed, millele loodi virtuaalsed. ja teostati KVM-i hüperviisorautode abil.
Me ei vaevanud liiga palju failisüsteemi nimega ja nimetasime seda lühidalt ARDFS-iks (arvake ära, mida see tähendab))
See prototüüp nägi hea välja (visuaalselt muidugi mitte, visuaalne kujundus veel puudus) ja näitas häid tulemusi nii jõudluse kui ka skaleerimise osas. Pärast esimest reaalset tulemust panime selle projekti käima, organiseerides täisväärtusliku arenduskeskkonna ja eraldi meeskonna, mis tegeles ainult vAIR-iga.
Just selleks ajaks oli küpsenud lahenduse üldarhitektuur, mis pole veel suuri muudatusi läbi teinud.
Sukeldumine ARDFS-failisüsteemi
ARDFS on vAIR vundament, mis pakub hajutatud, tõrketaluvusega andmesalvestust kogu klastris. Üks (kuid mitte ainus) ARDFS-i eripära on see, et see ei kasuta metaandmete ja haldamise jaoks täiendavaid spetsiaalseid servereid. See oli algselt mõeldud lahenduse konfigureerimise lihtsustamiseks ja selle töökindluse tagamiseks.
Säilitamise struktuur
Kõikides klastri sõlmedes korraldab ARDFS kogu saadaolevast kettaruumist loogilise kogumi. Oluline on mõista, et pool ei ole veel andmed ega vormindatud ruum, vaid lihtsalt märgistus, s.t. Kõik vAIR-i installitud sõlmed lisatakse klastrisse lisamisel automaatselt jagatud ARDFS-i basseini ja kettaressursid jagatakse automaatselt kogu klastri vahel (ja tulevikus andmete salvestamiseks). See lähenemine võimaldab sõlmede lisamist ja eemaldamist käigu pealt, ilma et see mõjutaks tõsiselt juba töötavat süsteemi. Need. süsteemi on väga lihtne skaleerida “tellistes”, vajadusel klastri sõlmede lisamine või eemaldamine.
ARDFS-i basseini peale lisatakse virtuaalsed kettad (virtuaalsete masinate salvestusobjektid), mis on üles ehitatud 4 megabaidistest virtuaalsetest plokkidest. Virtuaalsed kettad salvestavad andmeid otse. Veataluvuse skeem on seatud ka virtuaalse ketta tasemel.
Nagu võisite juba arvata, ei kasuta me ketta alamsüsteemi tõrketaluvuse tagamiseks RAID-i (sõltumatute ketaste liiasmassiivi) kontseptsiooni, vaid RAIN-i (sõltumatute sõlmede üleliigne massiiv). Need. Veataluvust mõõdetakse, automatiseeritakse ja hallatakse sõlmede, mitte ketaste põhjal. Kettad on loomulikult ka salvestusobjektiks, neid, nagu kõike muud, jälgitakse, nendega saab teha kõiki standardseid toiminguid, sealhulgas kohaliku riistvaralise RAID-i kokku panna, kuid klaster töötab spetsiaalselt sõlmedel.
Olukorras, kus soovite tõesti RAID-i (nt stsenaarium, mis toetab väikestes klastrites mitut tõrget), ei takista miski teil kasutada kohalikke RAID-kontrollereid ning ehitada venitatud salvestusruumi ja RAIN-arhitektuuri. See stsenaarium on üsna reaalajas ja meie poolt toetatud, seega räägime sellest artiklis, mis käsitleb tüüpilisi vAIR-i kasutamise stsenaariume.
Salvestusruumi tõrketaluvuse skeemid
VAIR-is võib virtuaalsete ketaste jaoks olla kaks tõrketaluvuse skeemi:
1) Replikatsioonitegur või lihtsalt replikatsioon – see veataluvuse meetod on sama lihtne kui kepp ja köis. Sünkroonne replikatsioon teostatakse sõlmede vahel koefitsiendiga 2 (2 koopiat klastri kohta) või 3 (vastavalt 3 koopiat). RF-2 võimaldab virtuaalsel kettal taluda klastri ühe sõlme rikkeid, kuid "sööb" poole kasulikust mahust ja RF-3 talub klastri kahe sõlme rikkeid, kuid jätab endale 2/2 sõlme tõrkest. kasulik maht oma vajadustele. See skeem on väga sarnane RAID-3-ga, see tähendab, et RF-1-s konfigureeritud virtuaalne ketas on klastri mis tahes sõlme rikke suhtes vastupidav. Sel juhul on andmetega kõik korras ja isegi I/O ei peatu. Kui langenud sõlm naaseb teenindusse, algab automaatne andmete taastamine/sünkroonimine.
Allpool on näited RF-2 ja RF-3 andmete jaotusest tavarežiimis ja rikkeolukorras.
Meil on virtuaalne masin mahuga 8MB unikaalseid (kasulikke) andmeid, mis töötab 4 vAIR-sõlmel. On selge, et tegelikkuses on ebatõenäoline, et nii väike maht tuleb, kuid ARDFS-i toimimise loogikat kajastava skeemi jaoks on see näide kõige arusaadavam. AB on 4 MB virtuaalsed plokid, mis sisaldavad ainulaadseid virtuaalse masina andmeid. RF-2 loob nendest plokkidest vastavalt kaks koopiat A1+A2 ja B1+B2. Need plokid on paigutatud sõlmedesse, vältides samade andmete ristumisi samas sõlmes, see tähendab, et koopia A1 ei asu samas sõlmes kui koopia A2. Sama B1 ja B2 puhul.
Kui üks sõlmedest ebaõnnestub (näiteks sõlm nr 3, mis sisaldab B1 koopiat), aktiveeritakse see koopia automaatselt sõlmes, kus selle koopia (st B2 koopia) pole.
Seega võib virtuaalne ketas (ja vastavalt ka VM) kergesti üle elada RF-2 skeemi ühe sõlme rikke.
Kuigi replikatsiooniskeem on lihtne ja töökindel, kannatab sama probleemi all nagu RAID1 – pole piisavalt kasutatavat ruumi.
2) Ülaltoodud probleemi lahendamiseks on olemas kustutuskodeerimine või kustutamiskood (tuntud ka kui "liigne kodeerimine", "kustutuskood" või "liigne kood"). EC on koondamisskeem, mis tagab andmete kõrge kättesaadavuse väiksema kettaruumiga võrreldes replikatsiooniga. Selle mehhanismi tööpõhimõte on sarnane RAID 5, 6, 6P-ga.
Kodeerimisel jagab EC protsess virtuaalse ploki (vaikimisi 4 MB) mitmeks väiksemaks "andmekilluks" olenevalt EC skeemist (näiteks skeem 2+1 jagab iga 4 MB ploki 2 2 MB tükiks). Seejärel genereerib see protsess "andmetükkide" jaoks "paarsustükid", mis ei ole suuremad kui üks eelnevalt jagatud osadest. Dekodeerimisel genereerib EC puuduvad tükid, lugedes kogu klastri "ellujäänud" andmeid.
Näiteks 2 + 1 EC skeemiga virtuaalne ketas, mis on rakendatud 4 klastri sõlmel, talub hõlpsalt klastri ühe sõlme rikkeid samamoodi nagu RF-2. Sel juhul on üldkulud väiksemad, eelkõige on RF-2 kasulik võimsuskoefitsient 2 ja EC 2+1 puhul 1,5.
Selle lihtsamaks kirjeldamiseks on sisuliselt see, et virtuaalne plokk jagatakse 2-8 (miks 2 kuni 8, vt allpool) "tükiks" ja nende jaoks arvutatakse sarnase mahuga paarsuse "tükid".
Selle tulemusena jaotuvad andmed ja paarsus ühtlaselt klastri kõigi sõlmede vahel. Samal ajal jaotab ARDFS, nagu ka replikatsiooni puhul, andmed automaatselt sõlmede vahel nii, et vältida identsete andmete (andmete koopiad ja nende paarsus) salvestamist samasse sõlme, et välistada võimalus andmete tõttu kaotada. asjaolule, et andmed ja nende paarsus satuvad ootamatult ühte salvestussõlme, mis ebaõnnestub.
Allpool on näide sama 8 MB virtuaalmasina ja 4 sõlmega, kuid EC 2+1 skeemiga.
Plokid A ja B on jagatud kaheks 2 MB suuruseks osaks (kaks, sest 2+1), st A1+A2 ja B1+B2. Erinevalt koopiast ei ole A1 A2 koopia, see on virtuaalne plokk A, mis on jagatud kaheks osaks, sama ka plokiga B. Kokku saame kaks komplekti 4MB, millest igaüks sisaldab kahte kahe MB tükki. Järgmisena arvutatakse iga komplekti paarsus mahuga, mis ei ületa ühte tükki (st 2 MB), saame täiendava + 2 pariteeti (AP ja BP). Kokku on meil 4×2 andmeid + 2×2 paarsus.
Järgmisena paigutatakse tükid sõlmede vahele nii, et andmed ei ristuks nende paarsusega. Need. A1 ja A2 ei asu AP-ga samas sõlmes.
Ühe sõlme (näiteks ka kolmanda) rikke korral taastatakse BP paarsusest automaatselt langenud plokk B1, mis on salvestatud sõlmele nr 2 ja aktiveeritakse sellel sõlmel, kus on puudub B-paarsus, st. tükk BP-st. Selles näites on see sõlm nr 1
Olen kindel, et lugejal on küsimus:
"Kõik, mida kirjeldasite, on juba ammu rakendanud nii konkurendid kui ka avatud lähtekoodiga lahendused. Mis vahe on teie EC-i rakendamisel ARDFS-is?"
Ja siis on ARDFS-i huvitavaid funktsioone.
Kustutage kodeerimine, keskendudes paindlikkusele
Algselt esitasime üsna paindliku EC X+Y skeemi, kus X on võrdne arvuga 2 kuni 8 ja Y on võrdne arvuga 1 kuni 8, kuid alati väiksem või võrdne X-ga. See skeem on esitatud paindlikkuse pärast. Andmetükkide (X) arvu suurendamine, milleks virtuaalne plokk jaotatakse, võimaldab vähendada üldkulusid, st suurendada kasutatavat ruumi.
Pariteedi tükkide (Y) arvu suurendamine suurendab virtuaalse ketta töökindlust. Mida suurem on Y väärtus, seda rohkem sõlme klastris võib ebaõnnestuda. Muidugi vähendab pariteedimahu suurendamine kasutatava võimsuse hulka, kuid see on hind, mida tuleb töökindluse eest maksta.
Jõudluse sõltuvus EC-ahelatest on peaaegu otsene: mida rohkem “tükke”, seda madalam on jõudlus; siin on muidugi vaja tasakaalustatud vaadet.
See lähenemisviis võimaldab administraatoritel konfigureerida venitatud salvestusruumi maksimaalse paindlikkusega. ARDFS-i basseinis saate kasutada mis tahes tõrketaluvuse skeeme ja nende kombinatsioone, mis on meie arvates samuti väga kasulikud.
Allpool on tabel, mis võrdleb mitut (mitte kõiki võimalikke) RF ja EC skeeme.
Tabelis on näha, et isegi kõige “frotee” kombinatsioon EC 8+7, mis võimaldab üheaegselt kaotada kuni 7 sõlme klastris, “sööb” vähem kasutatavat ruumi (1,875 versus 2) kui tavaline replikatsioon ja kaitseb 7 korda paremini , mis muudab selle kaitsemehhanismi, ehkki keerukamaks, palju atraktiivsemaks olukordades, kus piiratud kettaruumi tingimustes on vaja tagada maksimaalne töökindlus. Samal ajal peate mõistma, et iga "pluss" X-le või Y-le on täiendav jõudluse lisakulu, nii et töökindluse, säästu ja jõudluse kolmnurgas peate valima väga hoolikalt. Sel põhjusel pühendame kustutamise kodeerimise suuruse määramisele eraldi artikli.
Failisüsteemi töökindlus ja autonoomia
ARDFS töötab lokaalselt kõigis klastri sõlmedes ja sünkroonib need oma vahenditega spetsiaalsete Etherneti liideste kaudu. Oluline on see, et ARDFS sünkroonib sõltumatult mitte ainult andmeid, vaid ka salvestamisega seotud metaandmeid. ARDFS-i kallal töötades uurisime samaaegselt mitmeid olemasolevaid lahendusi ja avastasime, et paljud sünkroonivad failisüsteemi meta, kasutades välist hajutatud DBMS-i, mida me samuti kasutame sünkroonimiseks, kuid ainult konfiguratsioone, mitte FS-i metaandmeid (selle ja teiste seotud alamsüsteemide kohta järgmises artiklis).
FS-i metaandmete sünkroonimine välise DBMS-i abil on loomulikult toimiv lahendus, kuid siis sõltuks ARDFS-i salvestatud andmete järjepidevus välisest DBMS-ist ja selle käitumisest (ja ausalt öeldes on see kapriisne daam), mis meie arvamus on halb. Miks? Kui FS-i metaandmed saavad kahjustada, võib ka FS-i andmetele öelda "hüvasti", nii et otsustasime valida keerulisema, kuid usaldusväärsema tee.
Me tegime ARDFS-i jaoks ise metaandmete sünkroonimise alamsüsteemi ja see töötab külgnevatest alamsüsteemidest täiesti sõltumatult. Need. ükski teine alamsüsteem ei saa rikkuda ARDFS-i andmeid. Meie arvates on see kõige usaldusväärsem ja õigem viis, kuid aeg näitab, kas see ka tegelikult nii on. Lisaks on sellel lähenemisviisil täiendav eelis. ARDFS-i saab kasutada vAIR-ist sõltumatult, nagu venitatud salvestusruumi, mida kasutame kindlasti ka tulevastes toodetes.
Selle tulemusel saime ARDFS-i arendades paindliku ja töökindla failisüsteemi, mis annab valiku, kus on võimalik säästa mahtu või loobuda jõudlusest või teha üliusaldusväärset salvestusruumi mõistliku kuluga, kuid jõudlusnõudeid vähendades.
Koos lihtsa litsentsipoliitika ja paindliku tarnemudeliga (tulevikku vaadates on vAIR litsentsitud sõlmede kaupa ja tarnitakse kas tarkvara või tarkvarapaketina) võimaldab see teil väga täpselt kohandada lahendust paljude klientide vajaduste ja vajaduste järgi. siis seda tasakaalu kergesti säilitada.
Kellele seda imet vaja on?
Ühest küljest võib öelda, et turul on juba olemas tegijaid, kellel on hüperkonvergentsi vallas tõsised lahendused ja sinna me tegelikult ka liigume. Tundub, et see väide on tõsi, AGA...
Seevastu põldudele välja minnes ja klientidega suheldes näeme koos partneritega, et see pole sugugi nii. Hüperkonvergentsi ülesandeid on palju, mõnel pool inimesed lihtsalt ei teadnud, et sellised lahendused on olemas, teisal tundus see kallis, teisal katsetati alternatiivseid lahendusi ebaõnnestunult ja teisalt keelavad need sanktsioonide tõttu üldse ostmise. Üldiselt osutus põld kündmata, nii et läksime neitsi mulda kasvatama))).
Millal on salvestussüsteem parem kui GKS?
Turuga töötades küsitakse meilt sageli, millal on parem kasutada salvestussüsteemidega klassikalist skeemi ja millal hüperkonvergentset? Paljud GCS-i tootvad ettevõtted (eriti need, kelle portfellis pole salvestussüsteeme) ütlevad: "Salvestussüsteemid on vananenud, ainult hüperkonvergeeritud!" See on julge väide, kuid see ei peegelda täielikult tegelikkust.
Tõepoolest, salvestusturg liigub tõepoolest hüperkonvergentsi ja sarnaste lahenduste poole, kuid alati on olemas "aga".
Esiteks ei saa klassikalise skeemi järgi koos salvestussüsteemidega ehitatud andmekeskusi ja IT-infrastruktuure lihtsalt ümber ehitada, seega on selliste infrastruktuuride kaasajastamine ja valmimine veel 5-7 aasta pärand.
Teiseks on praegu ehitatav infrastruktuur suures osas (see tähendab Vene Föderatsiooni) ehitatud klassikalise skeemi järgi, kasutades salvestussüsteeme ja mitte sellepärast, et inimesed ei teaks hüperkonvergentsist, vaid seetõttu, et hüperkonvergentsi turg on uus, lahendused ja standardid pole veel kehtestatud , IT-inimesed pole veel koolitatud, neil on vähe kogemusi, kuid nad peavad ehitama andmekeskused siin ja praegu. Ja see trend kestab veel 3-5 aastat (ja siis veel üks pärand, vt punkt 1).
Kolmandaks on puhttehniline piirang täiendavatel väikestel viivitustel 2 millisekundit kirjutamise kohta (loomulikult kohalik vahemälu välja arvatud), mis on hajutatud salvestusruumi maksumus.
Noh, ärgem unustagem suurte füüsiliste serverite kasutamist, mis armastavad ketta alamsüsteemi vertikaalset skaleerimist.
On palju vajalikke ja populaarseid ülesandeid, mille puhul salvestussüsteemid käituvad paremini kui GCS. Siin muidugi ei nõustu meiega need tootjad, kelle tooteportfellis pole salvestussüsteeme, kuid me oleme valmis mõistlikult vaidlema. Loomulikult võrdleme mõlema toote arendajatena kindlasti ühes oma tulevases väljaandes salvestussüsteeme ja GCS-i, kus demonstreerime selgelt, kumb mis tingimustel parem on.
Ja kus töötavad hüperkonvergeeritud lahendused paremini kui salvestussüsteemid?
Ülaltoodud punktide põhjal saab teha kolm ilmset järeldust:
- Kui 2 millisekundit täiendavat latentsusaega salvestamiseks, mis järjepidevalt igas tootes esineb (praegu sünteetikast ei räägita, nanosekundeid saab näidata sünteetikal), on kriitilised, sobib hüperkonvergent.
- Kui suurte füüsiliste serverite koormust saab muuta paljudeks väikesteks virtuaalseteks ja sõlmede vahel jaotada, töötab seal hästi ka hüperkonvergents.
- Kui horisontaalne skaleerimine on kõrgem prioriteet kui vertikaalne skaleerimine, saab GCS ka seal suurepäraselt hakkama.
Mis need lahendused on?
- Kõik standardsed taristuteenused (kataloogiteenus, post, EDMS, failiserverid, väikesed või keskmised ERP- ja BI-süsteemid jne). Me nimetame seda "üldarvutuseks".
- Pilvepakkujate infrastruktuur, kus on vaja kiiresti ja standardiseeritud horisontaalselt laiendada ja hõlpsalt “lõikuda” klientide jaoks suur hulk virtuaalmasinaid.
- Virtuaalse töölaua infrastruktuur (VDI), kus paljud väikeste kasutajate virtuaalsed masinad töötavad ja hõljuvad vaikselt ühtses klastris.
- Haruvõrgud, kus iga haru vajab standardset, tõrketaluvat, kuid odavat infrastruktuuri, mis koosneb 15-20 virtuaalmasinast.
- Mis tahes hajutatud andmetöötlus (näiteks suurandmeteenused). Kus koormus ei lähe mitte "sügavusse", vaid "laiusesse".
- Testikeskkonnad, kus täiendavad väikesed viivitused on vastuvõetavad, kuid seal on eelarvepiirangud, kuna need on testid.
Hetkel oleme just nende ülesannete jaoks teinud AERODISK VAIR ja just neile keskendume (seni edukalt). Võib-olla see varsti muutub, sest... maailm ei seisa paigal.
Nii et ...
Sellega lõpetatakse esimene osa suurest artiklite sarjast, järgmises artiklis räägime lahenduse arhitektuurist ja kasutatud komponentidest.
Ootame küsimusi, ettepanekuid ja konstruktiivseid vaidlusi.
Allikas: www.habr.com