{"id":38542,"date":"2019-10-31T22:24:25","date_gmt":"2019-10-31T19:24:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs\/"},"modified":"2019-10-31T22:24:25","modified_gmt":"2019-10-31T19:24:25","slug":"giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"AERODISK vAIR h\u00fcperkonvergeeriv lahendus. P\u00f5hi on failis\u00fcsteem ARDFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"AERODISK<\/p>\n

<\/p>\n

Tere, Habr lugejad. K\u00e4esolevaga avame ts\u00fckli, mis r\u00e4\u00e4gib meie loodud h\u00fcperkonvergeeritud s\u00fcsteemist AERODISK vAIR. Alguses soovisime esimeses artiklis r\u00e4\u00e4kida k\u00f5igest, kuid s\u00fcsteem on \u00fcsna keeruline, seega v\u00f5tame hiire hammustuste kaupa. <\/p>\n

<\/p>\n

Alustame jutuga s\u00fcsteemi loomise ajaloost, s\u00fcveneme failis\u00fcsteemi ARDFS, mis on vAIR-i alus, ja arutame veidi ka selle lahenduse positsioneerimist Venemaa turul. <\/p>\n

<\/p>\n

Edasistes artiklites r\u00e4\u00e4gime l\u00e4hemalt erinevatest arhitektuurikomponentidest (klaster, h\u00fcperviisor, koormuse tasakaalustaja, j\u00e4lgimiss\u00fcsteem jne), seadistamisprotsessist, k\u00e4sitleme litsenseerimise k\u00fcsimusi, n\u00e4itame eraldi crash-teste ja loomulikult kirjutame koormustestimisest ja suurusest. Samuti p\u00fchendame eraldi artikli vAIR-i community-versioonile.<\/p>\n

<\/a><\/noindex><\/p>\n

AERODISK on nagu lugu andmesalvestusseadmest? Miks me \u00fcldse h\u00fcperkonvergentsiga tegelema hakkasime?<\/h2>\n

<\/p>\n

Alguses, umbes 2010. aastal, tuli meile m\u00f5te luua oma h\u00fcbriidkonvergeeritud lahendus. Sel ajal ei olnud turul veel Aerodiski ega sarnaseid (kaubanduslikult pakutavaid h\u00fcbriidkonvergeeritud s\u00fcsteeme). Meie \u00fclesanne oli j\u00e4rgmine: muuta rikka serverite komplekt, millel on lokaalsed kettad ja mis on \u00fchendatud Etherneti protokolli kaudu, jaotatud salvestuseks ning sealne virtuaalmasinate ja programmis\u00fcsteemi t\u00f6\u00f6ks. K\u00f5ike seda tuli teostada ilma SID (sest SID peale ja selle varustusele polnud raha, ja oma SID-d me siis veel ei olnud v\u00e4lja m\u00f5elnud).<\/p>\n

<\/p>\n

Oleme proovinud palju open source lahendusi ja l\u00f5puks lahendasime selle \u00fclesande, kuid lahendus oli v\u00e4ga keeruline ning seda oli raske korrata. Lisaks oli see lahendus laadi \u201eKas see t\u00f6\u00f6tab? \u00c4ra puutu!\u201c. Seet\u00f5ttu, kuigi oleme selle \u00fclesande lahendanud, ei arendanud me ideed edasi, et muuta meie t\u00f6\u00f6 tulemused t\u00e4ie\u00f5iguslikuks tooteks. <\/p>\n

<\/p>\n

P\u00e4rast seda juhtumit loobusime sellest ideest, kuid tunne, et see \u00fclesanne on lahendatav ja et sellise lahenduse kasu on ilmselge, ei j\u00e4tnud meid. Edasi liikuvad HCI tooted v\u00e4lisfirmadelt kinnitasid seda tunnet veelgi. <\/p>\n

<\/p>\n

Seet\u00f5ttu naasime 2016. aasta keskpaiku sellele \u00fclesandele, et luua t\u00f5eliselt t\u00e4ielik toode. Toona ei olnud meil veel mingeid suhteid investoritega, mist\u00f5ttu pidime arendusjaama ostma oma piiratud rahade eest. Ostsime Avitost kasutatud servereid ja l\u00fcliteid ning asusime t\u00f6\u00f6le.<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Peamine algne \u00fclesanne oli luua oma, kuigi lihtne, failis\u00fcsteem, mis suudaks automaatselt ja \u00fchtlaselt jaotada andmeid virtuaalsete blokkide kujul n-arvuliste klastrinoodide vahel, mis on \u00fchendatud Etherneti kaudu. Samuti pidi failis\u00fcsteem olema h\u00e4sti ja lihtsalt skaleeritav ning s\u00f5ltumatu k\u00fclgmistest s\u00fcsteemidest, st olema vAIR-ist eraldatav lihtsalt kui \"hoidla\".<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

vAIR-i esimene kontseptsioon<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Otsustasime teadlikult loobuda valmiduse avatud l\u00e4htekoodiga 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\u00e4rased, ning enne Aerodiski t\u00f6\u00f6le asumist viisime nende abil ellu mitu integreerimisprojekti. Kuid \u00fcks asi on t\u00e4ita kindlat kliendi \u00fclesannet, koolitada personali ning v\u00f5imalusel osta suurelt tarnijalt tugi, ja hoopis teine Asi on luua h\u00f5lpsasti replitseeriv toode, mida saab kasutada erinevate \u00fclesannete jaoks, millest meie, kui tarnija, ei pruugi isegi teadlikud olla. Seet\u00f5ttu otsustasime, et olemasolevad avatud l\u00e4htekoodiga tooted ei sobi meie teise eesm\u00e4rgi jaoks ning niisiis hakkasime ise jaotatud failis\u00fcsteemi arendama.
\nKaks aastat hiljem saavutasime mitme arendaja (kes \u00fchendasid t\u00f6\u00f6d vAIR-i arendamise ja klassikalise andmesalvestusseadme Engine'i vahel) kaudu teatud tulemuse.<\/p>\n

<\/p>\n

Aastal 2018 l\u00f5ime me lihtsa failis\u00fcsteemi ning t\u00e4iustasime seda vajalike lisadega. S\u00fcsteem \u00fchendab erinevate \u0441\u0435\u0440\u0432\u0435\u0440ite f\u00fc\u00fcsilised (kohalikud) ketas\u00fchendused \u00fcheks tasaseks puuks ja \u201el\u00f5ikab\u201d need virtuaalseteks plokkideks; seej\u00e4rel luuakse virtuaalsetest plokkidest erineva tulemuslikkuse ja t\u00f5rketaluvuse tasemega plokiseadmised, mille peal kujundatakse ja k\u00e4itatakse virtuaalmasinad KVM h\u00fcperviisori abil. <\/p>\n

<\/p>\n

Failis\u00fcsteemi nimi ei olnud meile kuigi oluline, seet\u00f5ttu nimetame selle lihtsalt ARDFS-iks (arvake, mida see t\u00e4histab))<\/p>\n

<\/p>\n

See protot\u00fc\u00fcp n\u00e4gi v\u00e4lja hea (loomulikult mitte visuaalselt, sel ajal polnud veel visuaalset kujundust) ja n\u00e4itas head j\u00f5udlust ning skaleeritavust. P\u00e4rast esimesi reaalseid tulemusi andsime projektile k\u00e4igu, korraldades korraliku arenduskeskkonna ja eraldi meeskonna, mis tegeles ainult vAIR-iga.<\/p>\n

<\/p>\n

Just sel ajal valmistas meeleheide \u00fcldine lahenduse arhitektuur, mis pole siiani t\u00f5siseid muutusi kogenud.<\/p>\n

<\/p>\n

Sukeldume ARDFS failis\u00fcsteemi<\/h2>\n

<\/p>\n

ARDFS on vAIR-i aluseks, mis tagab kogu klastri hajutatud rikke kindla andmete salvestamise. \u00dcks (kuid mitte ainus) ARDFS-i erip\u00e4ra on see, et see ei kasuta mingeid lisandusi andmete haldamiseks. dedikeeritud serverite<\/a> See oli algselt m\u00f5eldud lahenduse seadistamise lihtsustamiseks ja usaldusv\u00e4\u00e4rsuse tagamiseks. <\/p>\n

<\/p>\n

Salvestusstruktuur<\/h3>\n

<\/p>\n

ARDFS korraldab kogu klastri s\u00f5lmede raames loogilise puu kogu kergesti k\u00e4tte saadavast kettaruumist. On oluline m\u00f5ista, et puu ei ole veel andmed ega vormindatud ruum, vaid lihtsalt t\u00e4histus, s.t. iga s\u00f5lm, millel on installitud vAIR, lisatakse automaatselt klastri lisamisel ARDFS-i \u00fchisesse puusse ja kettaressursid muutuvad automaatselt k\u00f5igi klastri jaoks \u00fchisteks (ja on saadaval edasiste andmete salvestamiseks). Selline l\u00e4henemine v\u00f5imaldab s\u00f5lmede lisamist ja eemaldamist sujuvalt ilma, et see t\u00f5siselt m\u00f5jutaks juba toimivat s\u00fcsteemi. See t\u00e4hendab, et s\u00fcsteemi on v\u00e4ga lihtne \u201etelliskivina\u201d skaleerida, lisades v\u00f5i eemaldades s\u00f5lmi klastris vastavalt vajadusele.<\/p>\n

<\/p>\n

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. <\/p>\n

<\/p>\n

Nagu juba aimata v\u00f5is, ei kasuta me kettasalvestuss\u00fcsteemi katkemisvastasuse tagamiseks RAID (Redundant array of independent Disks) kontseptsiooni, vaid RAIN (Redundant array of independent Nodes) kontsepti. See t\u00e4hendab, et katkemisvastasust m\u00f5\u00f5detakse, automatiseeritakse ja hallatakse s\u00f5lmedest, mitte ketastest. Kettad on kahtlemata salvestusobjektid, neid j\u00e4lgitakse, ja nendega saab teha k\u00f5iki standardseid toiminguid, sealhulgas koguda kohalikku riistvaralist RAIDi, kuid klaster opereerib just s\u00f5lmedega. <\/p>\n

<\/p>\n

Kui tekib tugev soov RAID-i j\u00e4rele (n\u00e4iteks stsenaarium, mis toetab mitmeid rikkumisi v\u00e4ikestes klastrites), ei takista miski kasutada kohalikke RAID-kontrollereid ja nende peale luua hajutatud salvestuslahendust ning RAIN-architectuuri. Selline stsenaarium on t\u00e4iesti realistlik ja meie poolt toetatud, seet\u00f5ttu r\u00e4\u00e4gime sellest vAIR-i rakendusskeemide artiklis.<\/p>\n

<\/p>\n

Salvestuslahenduse t\u00f5rketaluvuse skeemid<\/h3>\n

<\/p>\n

vAIR-i virtuaalsete ketaste t\u00f5rketaluvuse skeeme v\u00f5ib olla kahte t\u00fc\u00fcpi:<\/p>\n

<\/p>\n

1) Replikatsioonifaktor ehk lihtsalt replikatsioon - see t\u00f5rketuksamise meetod on lihtne nagu \u201epulk ja n\u00f6\u00f6r\u201c. K\u00e4ib s\u00fcnkroonne replikatsioon node\u2019ide vahel, kus faktor on 2 (2 koopiat klastri kohta) v\u00f5i 3 (3 koopiat, vastavalt). RF-2 v\u00f5imaldab virtuaalsel kettal taluda \u00fche node'i rikke klastris, kuid \u201ej\u00e4relikult\u201c kasutab see \u00e4ra 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\u00e4ga RAID-1-le, st virtuaalplaat, mis on konfigureeritud RF-2-s, on kaitstud \u00fcksk\u00f5ik millise \u00fche node'i rikke eest klastris. Sellisel juhul on andmetega k\u00f5ik korras ja isegi sisendi-v\u00e4ljundi tegevus ei peatu. Kui rikutud node uuesti t\u00f6\u00f6korda tuleb, algab automaatne andmete taastamine\/s\u00fcnkroonimine. <\/p>\n

<\/p>\n

Allpool on toodud n\u00e4ited andmete jaotumisest RF-2 ja RF-3 t\u00f6\u00f6re\u017eiimis ja t\u00f5rgete olukordades.<\/p>\n

<\/p>\n

Meil on 8 MB suurune virtuaalne masin unikaalsete (kasutatavate) andmete osas, mis t\u00f6\u00f6tab neljal vAIR s\u00f5lmel. On selge, et reaalsuses ei pruugi selline v\u00e4ike maht olla, kuid ARDFS t\u00f6\u00f6loogikat n\u00e4itava skeemi jaoks on see n\u00e4ide k\u00f5ige arusaadavam. AB \u2013 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 \u201ejaotatakse\u201c s\u00f5lmede vahel, v\u00e4ltides samade andmete kattumist \u00fches s\u00f5lmes, st koopia A1 ei ole sama s\u00f5lmes koos koopia A2-ga. B1 ja B2 puhul on sarnane p\u00f5him\u00f5te.<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Kui \u00fcks s\u00f5lm, n\u00e4iteks s\u00f5lm nr 3, kus asub koopia B1, eba\u00f5nnestub, aktiveeritakse see koopia automaatselt s\u00f5lmes, kus pole koopia koopiat (st koopiat B2). <\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Seega suudavad virtuaalne ketas (ja VM) h\u00f5lpsasti taluda \u00fche s\u00f5lme, mis on v\u00e4lja l\u00fclitatud RF-2 skeemis.<\/p>\n

<\/p>\n

Replitseerimise skeem, kuigi see on lihtne ja usaldusv\u00e4\u00e4rne, kannatab sama probleemi all nagu RAID1 \u2013 kasulikku ruumi on v\u00e4he.<\/p>\n

<\/p>\n

2) Kustutuskoodimine ehk erasure coding (tuntud ka kui \"\u00fclearune koodimine\", \"kustutuskoodimine\" v\u00f5i \"\u00fclearuse kood\") on v\u00e4lja t\u00f6\u00f6tatud eespool mainitud probleemi lahendamiseks. EC on \u00fclearuse skeem, mis tagab andmete k\u00f5rge k\u00e4ttesaadavuse madalamate kettaruumi kuludega v\u00f5rreldes replikatsiooniga. Selle mehhanismi t\u00f6\u00f6p\u00f5him\u00f5te sarnaneb RAID 5, 6 ja 6P-iga. <\/p>\n

<\/p>\n

Koodimise protsessis jagab EC virtuaalne blokk (vaikimisi 4MB) v\u00e4iksemateks \"andmeosadeks\" vastavalt EC skeemile (n\u00e4iteks skeem 2+1 jagab iga 4MB bloki kaheks 2MB t\u00fckiks). Seej\u00e4rel genereerib protsess paranoiaosi suurusega mitte rohkem kui \u00fcks varem jagatud osa. Dekodeerimisel genereerib EC puuduvad t\u00fckid, lugedes \"elusolevaid\" andmeid \u00fcle kogu klastrite. <\/p>\n

<\/p>\n

N\u00e4iteks virtuaalne ketas EC skeemiga 2 + 1, teostatud 4 klastrinodega, talub rahulikult \u00fche 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. <\/p>\n

<\/p>\n

Lihtsustatult \u00f6eldes jagatakse virtuaalne plokk 2-8 (miks 2 kuni 8 - seda vaata allpool) \"t\u00fckiks\", ja nendele t\u00fckkidele arvutatakse sarnase mahuga \"t\u00fckid\" pariteedi. <\/p>\n

<\/p>\n

L\u00f5puks jaotatakse andmed ja pariteet \u00fchtlaselt kogu klastrisse. Nagu ka replikatsiooni puhul, jagab ARDFS automaatselt andmed nodide vahel nii, et ei lubata sama andmete (andmete ja nende pariteedi koopiaid) hoidmist \u00fches nodis, et v\u00e4ltida andmete kaotamist juhul, kui andmed ja nende pariteet satuvad ootamatult samasse salvestusnodisse, mis eba\u00f5nnestub. <\/p>\n

<\/p>\n

Allpool on n\u00e4ide sama virtuaalmasinaga, mille maht on 8 MB ja 4 nodiga, kuid juba EC 2+1 skeemi puhul. <\/p>\n

<\/p>\n

Plokk A ja B jagatakse kaheks t\u00fckiks, iga\u00fcks 2 MB (kaheks, sest 2+1), st A1+A2 ja B1+B2. Erinevalt koopiast ei ole A1 A2 koopia, see on virtuaalne A plokk, mis on jagatud kaheks osaks, sama on ploki B puhul. Kokku saame kaks komplekti, iga\u00fches 4 MB, milles on kaks kahtmegabaitist t\u00fckki. Edasi, iga\u00fche jaoks neist komplektidest arvutatakse pariteet, mille maht ei \u00fcleta \u00fchte t\u00fckki (st 2 MB), saame veel +2 pariteeti (A-P ja B-P). Kokku on 4×2 andmeid + 2×2 pariteeti.<\/p>\n

<\/p>\n

Seej\u00e4rel jaotatakse t\u00fckid nodidesse nii, et andmed ei kattuks nende pariteediga. See t\u00e4hendab, et A1 ja A2 ei paikne samas nodis A-P-ga.<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Kui \u00fcks nodo, eeldame, et kolmas, eba\u00f5nnestub, taastatakse rikutud plokk B1 automaatselt pariteedist B-P, mis on salvestatud nodo nr 2-s, ja aktiveeritakse n\u00f6dol, kus ei ole B pariteeti, see t\u00e4hendab t\u00fckki B-P. Antud n\u00e4ites on see nodo nr 1.<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Olen kindel, et lugejal tekib k\u00fcsimus:<\/p>\n

<\/p>\n

\u00abK\u00f5ik, mida te kirjeldasite, on juba ammu rakendatud konkurentide ja avatud l\u00e4htekoodiga lahendustes, mis teeb teie EC rakenduse ARDFS-is eriliseks?\u00bb<\/p><\/blockquote>\n

Edasi tulevad huvitavad omadused ARDFS-i toimimisest.<\/p>\n

<\/p>\n

Erasure coding paindlikkusele keskendudes.<\/h3>\n

<\/p>\n

Alguses planeerisime \u00fcsna paindliku EC X+Y skeemi, kus X on vahemikus 2 kuni 8 ja Y vahemikus 1 kuni 8, kuid alati v\u00e4iksem v\u00f5i v\u00f5rdne X-iga. See skeem on m\u00f5eldud paindlikkuse tagamiseks. Virtuaalse ploki andmeosade (X) arvu suurendamine v\u00e4hendab kulusid, see t\u00e4hendab, et see suurendab kasulikku ruumi.
\nParityosade (Y) arvu suurendamine suurendab virtuaalse ketta usaldusv\u00e4\u00e4rsust. Mida suurem on Y v\u00e4\u00e4rtus, seda rohkem s\u00f5lmi klastris v\u00f5ib eba\u00f5nnestuda. Loomulikult v\u00e4hendab pariteedi mahu suurendamine kasuliku mahutavuse suurust, kuid see on hind usaldusv\u00e4\u00e4rsuse eest. <\/p>\n

<\/p>\n

Skeemide EC j\u00f5udlus s\u00f5ltub peaaegu otseselt: mida rohkem on 't\u00fckke', seda madalam on j\u00f5udlus, siin on ilmselge, et vajalik on tasakaalustatud l\u00e4henemine. <\/p>\n

<\/p>\n

Selline l\u00e4henemine v\u00f5imaldab administraatoritel maksimaalselt paindlikult konfigureerida jaotatud salvestust. ARDFS-i partii raames saab kasutada mis tahes t\u00f5rkekindluse skeeme ja nende kombinatsioone, mis on meie arvates samuti v\u00e4ga kasulik. <\/p>\n

<\/p>\n

Allpool on toodud mitme (mitte k\u00f5ikide v\u00f5imalike) RF ja EC skeemide v\u00f5rdlustabel.<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Tabelist on n\u00e4ha, et isegi k\u00f5ige \"rikkam\" EC 8+7 kombinatsioon, mis lubab klastris samal ajal kaotada kuni 7 s\u00f5lme, v\u00f5tab v\u00e4hem 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\u00e4\u00e4rsus piiratud kettaruumi tingimustes. Samas tuleb m\u00f5ista, et iga \u201epluss\u201c X v\u00f5i Y juurde t\u00e4hendab t\u00e4iendavaid tootmiskulusid, seega tuleb usaldusv\u00e4\u00e4rsuse, s\u00e4\u00e4stmise ja tootlikkuse vahelises kolmnurgas teha valikud v\u00e4ga ettevaatlikult. Sel p\u00f5hjusel p\u00fchendame eraldi artikli eemaldava kodeerimise suurendamisele.<\/p>\n

<\/p>\n

\"AERODISK<\/p>\n

<\/p>\n

Failis\u00fcsteemi usaldusv\u00e4\u00e4rsus ja iseseisvus<\/h3>\n

<\/p>\n

ARDFS t\u00f6\u00f6tab k\u00f5igis klastrite nodedes lokaalselt ja s\u00fcnkroniseerib neid omaette vahenditega kaudu eraldatud Etherneti liideste. Oluline aspekt on see, et ARDFS s\u00fcnkroniseerib mitte ainult andmeid, vaid ka salvestamisega seotud metaandmeid. ARDFS-i arendamise k\u00e4igus uurisime paralleelselt mitmeid olemasolevaid lahendusi ja avastasime, et paljud teevad failis\u00fcsteemi metaandmete s\u00fcnkroniseerimist v\u00e4lise jaotatud andmebaasihalduriga, mida kasutame ka s\u00fcnkroniseerimiseks, kuid ainult konfiguratsioonide, mitte failis\u00fcsteemi metaandmete jaoks (sellest ja teistest seotud alams\u00fcsteemidest tuleb j\u00e4rgmises artiklis). <\/p>\n

<\/p>\n

Failis\u00fcsteemi metaandmete s\u00fcnkroniseerimine v\u00e4lise andmebaasihalduriga on loomulikult toimiv lahendus, kuid siis s\u00f5ltuks ARDFS-is salvestatud andmete j\u00e4rjepidevus v\u00e4lisest andmebaasihaldurist ja selle k\u00e4itumisest (ja see on otsekui \u00fcsnagi kapriisne daam), mis meie arvates pole hea. Miks? Kui failis\u00fcsteemi metaandmed saavad kahjustada, siis saab ka failis\u00fcsteemi enda andmetele \u00f6elda \"head aega\", mist\u00f5ttu otsustasime minna keerukamat, kuid usaldusv\u00e4\u00e4rsemat teed. <\/p>\n

<\/p>\n

ARDFS-i metaandmete s\u00fcnkroonimise alams\u00fcsteemi l\u00f5ime me ise ning see toimib t\u00e4iesti iseseisvalt k\u00f5rvalasuvate alams\u00fcsteemide suhtes. See t\u00e4hendab, et \u00fckski teine alams\u00fcsteem ei saa ARDFS-i andmeid kahjustada. Meie arvates on see k\u00f5ige usaldusv\u00e4\u00e4rsem ja \u00f5igem tee; kas see t\u00f5esti nii on, n\u00e4itab aeg. Lisaks toob selline l\u00e4henemine kaasa ka t\u00e4iendava eelise. ARDFS-i saab kasutada iseseisvalt vAIR-ist, lihtsalt kui laienenud salvestusruumina, mida me kindlasti kasutanud oleme tulevastes toodetes.<\/p>\n

<\/p>\n

Kokkuv\u00f5ttes, arendades ARDFS-i, saime paindliku ja usaldusv\u00e4\u00e4rse failis\u00fcsteemi, mis annab valiku, kus saab salvestusmahult kokku hoida v\u00f5i andmeid optimeerida, v\u00f5i teha salvestus ruumi \u00fclimalt usaldusv\u00e4\u00e4rseks m\u00f5istliku hinna eest, kuid v\u00e4hendades n\u00f5udmisi j\u00f5udlusele. <\/p>\n

<\/p>\n

Koos lihtsa litsentsipoliitika ja paindliku tarnemudeliga (tulevikku vaadates, litsentseeritakse vAIR s\u00f5lmedena ning tarnitakse kas tarkvarana v\u00f5i kui PAK) v\u00f5imaldab see t\u00e4pselt kohandada lahendust erinevatele klientide n\u00f5udmistele ning hiljem kergesti seda tasakaalu hoida. <\/p>\n

<\/p>\n

Kellele see ime vajalik on?<\/h2>\n

<\/p>\n

\u00dchest k\u00fcljest v\u00f5ib \u00f6elda, et turul on juba m\u00e4ngijad, kellel on t\u00f5sised h\u00fcperkonvergeeritud lahendused, ja kuhu me tegelikult siseneme. See v\u00e4ide tundub t\u00f5ene, KUID...<\/p>\n

<\/p>\n

Teisest k\u00fcljest, kui minna \"v\u00e4lja ja p\u00f5llule\" ning vestelda klientidega, n\u00e4eme meie ja meie partnerid, et asi ei ole sugugi nii. H\u00fcperkonvergeeritud lahendusi vajavaid probleeme on palju: m\u00f5nes kohas ei teata, et sellised lahendused eksisteerivad, m\u00f5nes kohas tunduvad need liiga kallid, m\u00f5nes kohas on alternatiivsete lahenduste testid eba\u00f5nnestunud, ja m\u00f5nes kohas on ostmisele lihtsalt keeld, sest sanktsioonid. \u00dches\u00f5naga, p\u00f5ld on osutunud harimatuks, seet\u00f5ttu l\u00e4ksime me seda harima))). <\/p>\n

<\/p>\n

Millal on S\u00dcD parem kui GKS?<\/h3>\n

<\/p>\n

Turuga t\u00f6\u00f6tades k\u00fcsitakse meid sageli, millal on parem rakendada klassikalist skeemi S\u00dcD-ga ja millal - h\u00fcperkonvergeerumisega? Paljud GKS-i tootmisettev\u00f5tted (eriti need, kellel portfellis ei ole S\u00dcD-d) \u00fctlevad: \u201eS\u00dcD on oma aja elanud, h\u00fcperkonvergeerumine ainult!\u201c. See on julge v\u00e4ide, kuid ei peegelda olukorda t\u00e4iesti \u00f5igesti. <\/p>\n

<\/p>\n

T\u00f5tt-\u00f6elda liigub S\u00dcD turg t\u00f5eliselt h\u00fcperkonvergeeritud ja sarnaste lahenduste suunas, kuid alati on olemas \u201eaga\u201c.<\/p>\n

<\/p>\n

Esiteks, klassikalise jaotusega andmekeskused ja IT-infrastruktuurid ei saa lihtsalt niisama \u00fcmber ehitada, seega selliste infrastruktuuride moderniseerimine ja t\u00e4iendamine on p\u00e4rand, mis kestab veel 5-7 aastat.<\/p>\n

<\/p>\n

Teiseks, need infrastruktuurid, mis praegu massiliselt ehitatakse (peamine fookus Venemaale), rajatakse klassikalise skeemi j\u00e4rgi, kasutades jaotatud salvestust, mitte seet\u00f5ttu, et inimesed ei tea h\u00fcperkonvergentsist, vaid seet\u00f5ttu, et h\u00fcperkonvergendi turg on uus, lahendused ja standardid pole veel kindlaks kujunenud, IT-spetsialiste pole veel koolitatud, kogemust on v\u00e4he, ja andmekeskusi tuleb ehitada siin ja praegu. See suundumus j\u00e4tkub veel 3-5 aastat (ja siis tuleb veel p\u00e4rand, vt punkt 1).<\/p>\n

<\/p>\n

Kolmandaks, on puhas tehniline piirang, et kirjutamise lisaviivitused on 2 millisekundit (ilma kohalikku vahem\u00e4lu arvesse v\u00f5tmata, muidugi), mis on hind jaotatud salvestamise eest. <\/p>\n

<\/p>\n

Ja \u00e4rgem unustagem suurte f\u00fc\u00fcsiliste serverite kasutamist, mis eelistavad vertikaalset salvestusmahtu.<\/p>\n

<\/p>\n

On palju vajalikke ja populaarseid \u00fclesandeid, kus SSi toimib paremini kui HSi. Loomulikult ei n\u00f5ustu meiega need tootjad, kelle tooteportfellis pole SSi, kuid me oleme valmis veenvalt arutlema. Loodetavasti, kui me, nagu nende kahe toote arendajad, tulevikus avaldame v\u00f5rdluse SSI ja HSi vahel, n\u00e4itame selgelt, millistes tingimustes kumb on parem.<\/p>\n

<\/p>\n

Kus siis h\u00fcperkonvergeeritud lahendused t\u00f6\u00f6tavad paremini kui SSI?<\/h3>\n

<\/p>\n

\u00dclaltoodud teesidest l\u00e4htuvalt saab teha kolm ilmselget j\u00e4reldust: <\/p>\n

<\/p>\n

    \n
  1. Seal, kus t\u00e4iendavad 2 millisekundit viivitust kirjutamisel, mis p\u00fcsivalt tekib igas tootmises (praegu ei r\u00e4\u00e4gi me s\u00fcnteetilisest, s\u00fcnteetikas v\u00f5ib ka nanosekundeid n\u00e4idata), ei ole kriitilised, sobib h\u00fcperkonvergeeritud lahendus.<\/li>\n
  2. Seal, kus koormus suurtest f\u00fc\u00fcsilistest serveritest saab muuta paljude v\u00e4ikeste virtuaalsete hulka ja jaotada nodide vahel, sobib h\u00fcperkonvergeeritud lahendus samuti suurep\u00e4raselt.<\/li>\n
  3. Seal, kus horisontaalne skaleerimine on prioriteediks k\u00f5rgem kui vertikaalne, sealgi sobivad HSi suurep\u00e4raselt.<\/li>\n<\/ol>\n

    <\/p>\n

    Mis need lahendused on?<\/h3>\n

    <\/p>\n

      \n
    1. K\u00f5ik standardsed infrastruktuuri teenused (katalooge teenus, e-post, ESM, failiserverid, v\u00e4ikesed v\u00f5i keskmised ERP ja BI s\u00fcsteemid jne). Me nimetame seda '\u00fcldiseks arvutamiseks'. <\/li>\n
    2. Pilveteenuste infrastruktuur, kus on vajalik kiiresti ja standardiseeritult horisontaalset skaleerimist ning lihtsasti suurt hulka virtuaalmasinaid klientide jaoks 'jaotades'.<\/li>\n
    3. Infrastruktuur virtuaalsed t\u00f6\u00f6laudade<\/a> (VDI), kus palju v\u00e4ikeseid kasutaja virtuaalmasinaid k\u00e4ivitatakse ja rahulikult 'ujuvad' \u00fchesuguses klastris.<\/li>\n
    4. Filiaaliv\u00f5rgud, kus igas filiaalis on vaja standardset, t\u00f5rkekindlat, kuid samas odavat infrastruktuuri 15-20 virtuaalmasinaga.<\/li>\n
    5. Igak\u00fclgsed jaotatud arvutused (big data teenused, n\u00e4iteks). Seal, kus koormus ei liigu 's\u00fcgavusele', vaid 'laiusele'. <\/li>\n
    6. Testkeskkonnad, kus on lubatud lisaviivitused, kuid on eelarve piirangud, kuna tegemist on testidega.<\/li>\n<\/ol>\n

      <\/p>\n

      Praegu oleme just nende \u00fclesannete jaoks loonud AERODISK vAIR ja suuname t\u00e4helepanu neile (praegu edukalt). V\u00f5ib-olla muutub see peagi, kuna maailm ei seisa paigal.<\/p>\n

      <\/p>\n

      Nii et...<\/h3>\n

      <\/p>\n

      Selle artikli esimene osa on n\u00fc\u00fcd l\u00e4bi, j\u00e4rgmises osas r\u00e4\u00e4gime lahenduse arhitektuurist ja kasutatud komponentidest.<\/p>\n

      <\/p>\n

      Ootame k\u00fcsimusi, ettepanekuid ja konstruktiivseid arutelusid.<\/p>\n

      Allikas: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28919,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47H\u00fcperkonvergente lahendus AERODISK vAIR. Alus \u2014 failis\u00fcsteem ARDFS | ProHoster","description":"Tere, Habr lugejad. Selle artikliga alustame seeriat, mis r\u00e4\u00e4gib meie v\u00e4ljat\u00f6\u00f6tatud h\u00fcperkonvergentsest s\u00fcsteemist AERODISK vAIR. Esialgu soovisime, et esimene artikkel r\u00e4\u00e4giks k\u00f5igest, kuid s\u00fcsteem on \u00fcsna keeruline, seet\u00f5ttu s\u00f6\u00f6me elevanti osade kaupa. Alustame s\u00fcsteemi loomise ajalooga, s\u00fcveneme ARDFS failis\u00fcsteemi, mis on vAIR'i alus, samuti","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0413\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 AERODISK vAIR. \u041e\u0441\u043d\u043e\u0432\u0430 \u2014 \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 ARDFS | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435","og:url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:24:25+00:00","article:modified_time":"2019-10-31T19:24:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38542","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 13:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:07:40","updated":"2026-02-09 13:06:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}