{"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":"Avaldatud erakorraline v\u00e4ljaanne meiliserveri jaoks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Avaldatud<\/p>\n

<\/p>\n

Tere, Habra lugejad. Selle artikli kaudu avame ts\u00fckli, mis r\u00e4\u00e4gib meie loodud h\u00fcperkonvergentse s\u00fcsteemist AERODISK vAIR. Alguses soovisime esimeses artiklis r\u00e4\u00e4kida k\u00f5igest, kuid s\u00fcsteem on \u00fcsna keeruline, seega v\u00f5tame selle ette osade kaupa. <\/p>\n

<\/p>\n

Alustame s\u00fcsteemi loomise ajaloost, sukeldume ARDFS failis\u00fcsteemi, mis on vAIRi alus, ja arutame veidi ka selle lahenduse positsioneerimist Venemaa turul. <\/p>\n

<\/p>\n

Tulevastes artiklites r\u00e4\u00e4gime l\u00e4hemalt erinevatest arhitektuurilisest komponentidest (kluster, h\u00fcperviisor, koormuse tasakaalustaja, j\u00e4lgimiss\u00fcsteem jne), seadistamisprotsessist, t\u00f5statame litsentsimise k\u00fcsimused, n\u00e4itame eraldi kokkuvarisemiskatse l\u00e4bi ja loomulikult kirjutame koormustestimisest ja suurendamisest. Samuti p\u00fchendame eraldi artikli vAIRi community-versioonile.<\/p>\n

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

AERODISK on kui lugu andmehoidlatest? V\u00f5i miks me \u00fcldse h\u00fcperkonvergentsiga tegelema hakkasime?<\/h2>\n

<\/p>\n

Algne idee luua oma h\u00fcperkonvergent tekkis meil kuskil 2010. aasta paiku. Sel ajal ei olnud ei AERODISK ega sarnaseid lahendusi (kommertslikud kastis\u00fcsteemid) turul. Meie \u00fclesanne oli j\u00e4rgmine: serverite komplekt, millel on kohalike ketaste \u00fchendamine Etherneti protokolli kaudu, tuli muuta hajutatud salvestuseks ning sealjuures jooksutada virtuaalmasinaid ja tarkvara v\u00f5rku. K\u00f5ik see pidi toimuma ilma andmehoidlate s\u00fcsteemideta (sest andmehoidlate s\u00fcsteemi ja selle tarvikute jaoks polnud lihtsalt raha, ja oma andmehoidlat me siis veel ei leiutanud).<\/p>\n

<\/p>\n

Proovisime palju avatud l\u00e4htekoodiga lahendusi, kuid lahendasime selle \u00fclesande, kuigi lahendus oli v\u00e4ga keeruline ning seda oli raske korrata. Pealegi oli see lahendus pigem selline \u201eKas see t\u00f6\u00f6tab? \u00c4ra vaata!\u201d Seet\u00f5ttu, kui selle \u00fclesande lahendasime, ei hakanud me enam edasi arendama ideed, et meie t\u00f6\u00f6 tulemus muuta t\u00e4ielikuks tooteks. <\/p>\n

<\/p>\n

P\u00e4rast seda juhtumit j\u00e4tsime selle idee k\u00f5rvale, kuid tunne, et see \u00fclesanne on t\u00e4iesti lahendatav ja selle lahenduse kasu on rohkem kui ilmne, ei j\u00e4tnud meid. Edasi tulid v\u00e4liskompaniide v\u00e4lja toodud HCI-tooted, mis ainult kinnitasid seda tunnet. <\/p>\n

<\/p>\n

Seet\u00f5ttu naasisime 2016. aasta keskel selle \u00fclesande juurde, luues t\u00e4ie\u00f5iguslikku toodet. Siis puudusid meil igasugused suhted investoritega, seega pidime arendusstandardi ostma oma v\u00e4heste rahade eest. Ostes Avitost kasutatud servereid ja l\u00fcliteid, asusime t\u00f6\u00f6le.<\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

Peamine algne \u00fclesanne oli luua oma, kuigi lihtne, failis\u00fcsteem, mis suudaks automaatselt ja \u00fchtlaselt jaotada andmeid virtuaalsete plokkidena klastrisse kuuluvatesse n-isse s\u00f5lmedesse, mis on \u00fchendatud Ethernet'i kaudu. Samal ajal peab failis\u00fcsteem h\u00e4sti ja lihtsalt skaleeruma ning olema s\u00f5ltumatu k\u00fclgnevate s\u00fcsteemide, st olema isoleeritud vAIR-i poolest kui \"lihtsalt salvesti\".<\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

Esimene vAIR kontseptsioon<\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

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\u00e4rased ja enne Aerodiski t\u00f6\u00f6tamist oleme nendega realiseerinud rohkem kui \u00fche integratsiooniprojekti. Kuid \u00fche ettev\u00f5tja konkreetse \u00fclesande t\u00e4itmine, personali koolitamine ja suure m\u00fc\u00fcgi toetuse ostmine on \u00fcks asi, samas kui lihtsalt reprodutseeritava toote loomine, mida kasutatakse erinevate \u00fclesannete jaoks, millest me kui m\u00fc\u00fcja v\u00f5ib-olla isegi ise ei tea, on hoopis teine asi. Seet\u00f5ttu ei sobinud meile olemasolevad open source tooted teise eesm\u00e4rgi saavutamiseks ja otsustasime luua hajutatud failis\u00fcsteemi ise.
\nKaks aastat hiljem saavutas v\u00e4heste arendajate agiteerimisega (kes olid kombineerinud vAIR-i arendust klassikalise andmesalvestus\u00fclesande Engine'i arendamisega) teatud tulemuse.<\/p>\n

<\/p>\n

2018. aastaks olime kirjutanud k\u00f5ige lihtsama failis\u00fcsteemi ning t\u00e4iendanud selle vajaliku raamistiku. S\u00fcsteem \u00fchendas siseinterneti kaudu erinevatelt serveritelt f\u00fc\u00fcsilised (kohalikud) kettad \u00fcheks tasaseks basseiniks ning \"l\u00f5ikas\" need virtuaalseteks plokkideks; seej\u00e4rel loodi virtuaalsetest plokkidest plokiseadmed, millel oli teatud raskusastme taluvus ja mille peal loodi ja k\u00e4idi virtuaalmasinad KVM h\u00fcperviisori abil. <\/p>\n

<\/p>\n

Me ei hakanud failis\u00fcsteemi nime \u00fcle palju muretsema ja nimetasime selle lakooniliselt ARDFS-iks (arva, mida see t\u00e4hendab))<\/p>\n

<\/p>\n

See protot\u00fc\u00fcp n\u00e4gi hea v\u00e4lja (visuaalselt, muidugi, visuaalne kujundus polnud siis veel olemas) ja n\u00e4itas h\u00e4id tulemusi j\u00f5udluse ja skaleeritavuse osas. P\u00e4rast esimest reaalselt saavutatud tulemust andsime sellele projektile edasi, korraldades t\u00f5elise arenduskeskkonna ning eraldi meeskonna, mis t\u00f6\u00f6tas ainult vAIR-i kallal.<\/p>\n

<\/p>\n

Just sellisel ajal valmistasime ette lahenduse \u00fcldise arhitektuuri, mis ei ole siiani t\u00f5siseid muudatusi kogenud.<\/p>\n

<\/p>\n

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

<\/p>\n

ARDFS on vAIR-i alus, mis tagab kogu klastrite jaotatud t\u00f5rketaluvuse andmete salvestamise. \u00dcks (aga mitte ainus) ARDFS-i silmapaistvamaid omadusi on see, et see ei kasuta mingeid lisandeid p\u00fchendatud serveritele<\/a> meta ja haldamise jaoks. Nii oli algselt plaanitud lahenduse konfigureerimise lihtsustamiseks ja usaldusv\u00e4\u00e4rsuse tagamiseks. <\/p>\n

<\/p>\n

Salvestamise struktuur<\/h3>\n

<\/p>\n

Kogu klastrite node\u2019de raames organiseerib ARDFS loogilise basseini kogu saadaval olevast kettaruumist. On oluline m\u00f5ista, et bassein ei ole veel andmed ja mitte formaaditud ruum, vaid lihtsalt joonistus, st k\u00f5ik node\u2019d, kus on installitud vAIR, lisatakse automaatselt ARDFS-i \u00fchisesse basseini ja kettaressursid muutuvad automaatselt k\u00f5igis klastrites jagatavaks (ja tulevaste andmete salvestamiseks kergesti k\u00e4ttesaadavaks). Selline l\u00e4henemine v\u00f5imaldab kiiresti lisada ja eemaldada node\u2019sid ilma t\u00f5sise m\u00f5juta juba t\u00f6\u00f6tavale s\u00fcsteemile. See t\u00e4hendab, et s\u00fcsteemi on v\u00e4ga lihtne skaleerida \u201etellistega\u201c, lisades v\u00f5i eemaldades node\u2019e klastris vastavalt vajadusele.<\/p>\n

<\/p>\n

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\u00e4\u00e4ratakse samuti v\u00e4lja t\u00f5rketaluvuse skeem. <\/p>\n

<\/p>\n

Nagu juba v\u00f5is arvata, ei kasuta me kettas\u00fcsteemi t\u00f5rke taluvuse tagamiseks RAID-i (Redundant array of independent Disks) kontseptsiooni, vaid RAIN-i (Redundant array of independent Nodes). St. t\u00f5rke taluvus m\u00f5\u00f5detakse, automatiseeritakse ja hallatakse s\u00f5lmedest, mitte ketastest. Kettad on loomulikult ka salvestusobjekt, neid j\u00e4lgitakse nagu k\u00f5ike muud, nendega saab teha k\u00f5iki tavap\u00e4raseid toiminguid, sealhulgas koguda kohalikku riistvara RAID-i, kuid klaster opereerib just nimelt s\u00f5lmedega. <\/p>\n

<\/p>\n

Kui olukord on selline, et v\u00e4ga soovitakse RAID-i (n\u00e4iteks stsenaarium, mis toetab mitmeid rikkeid v\u00e4ikestes klastrites), ei takista miski kasutada kohalikke RAID-kontrollereid, ning nende peale luua venitatud salvestus ja RAIN-architektuur. Selline stsenaarium on t\u00e4iesti eluj\u00f5uline ja selle toetamine, mist\u00f5ttu r\u00e4\u00e4gime sellest vAIR-i t\u00fc\u00fcpiliste rakenduste stsenaariumide artiklis.<\/p>\n

<\/p>\n

Salvestuss\u00fcsteemi t\u00f5rke taluvuse skeemid<\/h3>\n

<\/p>\n

vAIR-i virtuaalsete kettaste t\u00f5rke taluvuse skeeme v\u00f5ib olla kahte t\u00fc\u00fcpi:<\/p>\n

<\/p>\n

1) Replikatsioonifaktori v\u00f5i lihtsalt replikatsiooni meetod, mis on t\u00f5rke taluvuse meetod, mis on sama lihtne kui \u201epuu ja n\u00f6\u00f6r\u201c. S\u00f5lmede vahel toimub s\u00fcnkroonne replikatsioon 2:1 (2 koopiat klastris) v\u00f5i 3:1 (3 koopiat, vastavalt). RF-2 v\u00f5imaldab virtuaalsel kettal taluda \u00fche s\u00f5lme riket klastris, kuid \u201ekulutab\u201c poole kasulikust mahust, samas kui RF-3 talub 2 s\u00f5lme riket klastris, kuid reserveerib juba 2\/3 kasulikust mahust oma vajaduste katmiseks. See skeem sarnaneb v\u00e4ga RAID-1-le, st virtuaalne kettas, mis on konfigureeritud RF-2, on rikke suhtes talutav mistahes \u00fcksikule s\u00f5lmele klastris. Sel juhul on andmetega k\u00f5ik korras ja isegi sisse-\/v\u00e4ljaandmine ei peatu. Kui langenud s\u00f5lm tagasi t\u00f6\u00f6le tuleb, algab automaatne taastamine\/s\u00fcnkroniseerimine andmetega. <\/p>\n

<\/p>\n

Allpool on toodud n\u00e4ited RF-2 ja RF-3 andmete jaotumisest normaalses re\u017eiimis ja t\u00f5rgete ajal.<\/p>\n

<\/p>\n

Meil on 8 MB ainulaadse (kasutaja) andmemahu virtuaalmasin, mis t\u00f6\u00f6tab 4 vAIR nodi peal. On selge, et reaalsuses on selline v\u00e4ike maht ebat\u00f5en\u00e4oline, kuid see n\u00e4ide illustreerib ARDFS-i t\u00f6\u00f6logikat k\u00f5ige paremini. AB \u2013 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\u00e4ltides sama teabe kattumist \u00fches nodis, st koopia A1 ei asu \u00fches nodis koos koopia A2-ga. B1 ja B2 puhul on analoogne l\u00e4henemine.<\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

Kui \u00fcks nodidest (n\u00e4iteks nod \u21163, kus asub B1 koopia) t\u00f5rkub, aktiveeritakse see koopia automaatselt nodis, kus ei ole tema koopia kopeerimist (st koopia B2). <\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

Nii on virtuaaldisk (ja vastavalt ka VM) lihtsasti vastupidav \u00fche nodi t\u00f5rkele RF-2 skeeme kasutades.<\/p>\n

<\/p>\n

Replikatsiooniskeem, hoolimata oma lihtsusest ja usaldusv\u00e4\u00e4rsusest, kannatab sama probleemi all nagu RAID1 \u2013 v\u00e4he kasulikku ruumi.<\/p>\n

<\/p>\n

2) Erasure coding ehk kustutuskoodimine (tuntud ka kui 'liigne koodimine', 'kustutuskood' v\u00f5i '\u00fclej\u00e4\u00e4nud kood') eksisteerib selle probleemi lahendamiseks. EC \u2013 see on \u00fclej\u00e4\u00e4giskeem, mis tagab andmete k\u00f5rge k\u00e4ttesaadavuse v\u00e4iksemate kuludega v\u00f5rreldes replikatsiooniga. Selle mehhanismi t\u00f6\u00f6p\u00f5him\u00f5te sarnaneb RAID 5, 6, 6P-ga. <\/p>\n

<\/p>\n

Koodimise protsess EC jagab virtuaalse ploki (vaikimisi 4 MB) mitmeks v\u00e4iksemaks 'andmeplokiks' s\u00f5ltuvalt EC skeemist (n\u00e4iteks skeem 2+1 jagab iga 4 MB ploki 2 osaks 2 MB). Seej\u00e4rel genereerib see protsess 'pariteedi plokid', mis ei \u00fcleta eelnevalt jagatud osade suurust. Dekodeerimisel genereerib EC puuduolevad osad, lugedes 'elluj\u00e4\u00e4nud' andmeid kogu klastrist. <\/p>\n

<\/p>\n

N\u00e4iteks virtuaaldisk EC skeemiga 2+1, mis on rakendatud 4 nodiga klastris, talub rahulikult \u00fche nodi t\u00f5rget klastris samal viisil nagu RF-2. Sel juhul on kulud madalamad, n\u00e4iteks RF-2 efektiivsuse koefitsient on 2, samas kui EC 2+1 puhul on see 1,5. <\/p>\n

<\/p>\n

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

<\/p>\n

L\u00f5puks jagatakse andmed ja pariteet v\u00f5rdselt k\u00f5ikide 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\u00e4ilitamist \u00fchel nodil, et minimeerida v\u00f5imalust andmete kaotamiseks, juhul kui andmed ja nende pariteet satuvad \u00fchel salvestusnodule kokku, mis eba\u00f5nnestub. <\/p>\n

<\/p>\n

Allpool on n\u00e4ide sama virtuaalmasinaga, mille RAM on 8 MB ja nelja nodiga, kuid n\u00fc\u00fcd EC skeemiga 2+1. <\/p>\n

<\/p>\n

Blokid A ja B jagunevad kaheks osaks, iga\u00fche maht on 2 MB (kahe, sest 2+1), see t\u00e4hendab A1+A2 ja B1+B2. Erinevalt replikast ei ole A1 koopia A2-st, see on virtuaalne blok A, jagatud kaheks osaks, sama kehtib blok B kohta. Kokku saame kaks komplekti, iga\u00fches on 4 MB, milles on kaks kahest megabaitist t\u00fckki. Seej\u00e4rel arvutatakse iga\u00fche jaoks pariteet, mille maht ei \u00fcleta \u00fchte t\u00fckki (st 2 MB), seega saame t\u00e4iendavalt + 2 pariteedit\u00fckki (A-P ja B-P). Kokku on 4\u00d72 andmeid + 2\u00d72 pariteeti.<\/p>\n

<\/p>\n

Seej\u00e4rel jaotatakse t\u00fckid nodide vahel nii, et andmed ei j\u00e4\u00e4ks nende pariteediga kokku. St A1 ja A2 ei paikne samal nodil koos A-P-ga.<\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

\u00dche nodi (\u00fctleme, et sama kolmas) t\u00f5rke korral taastatakse eba\u00f5nnestunud plokk B1 automaatselt pariteedist B-P, mis asub nodil nr 2, ja aktiveeritakse nodil, kus ei ole B-pariteeti, st t\u00fckk B-P. Selles n\u00e4ites on see nodi nr 1.<\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

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

<\/p>\n

\u201eK\u00f5ik, mida te kirjeldasite, on juba ammu rakendatud konkurentide ja avatud l\u00e4htekoodiga lahendustes. Mis on teie ARDFS EC rakenduse erinevus?\u201c<\/p><\/blockquote>\n

Edasi tulevad huvitavad omadused ARDFS t\u00f6\u00f6protsessis.<\/p>\n

<\/p>\n

Kustutuskood, millel on paindlikkuse r\u00f5hk<\/h3>\n

<\/p>\n

Alguses planeerisime \u00fcsna paindliku EC skeemi X+Y, 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 ette n\u00e4htud paindlikkuse saavutamiseks. Andmete t\u00fckkide arvu (X) suurendamine, millesse virtuaalne plokk jagatakse, v\u00e4hendab \u00fclehead, st suurendab kasulikku ruumi.
\nPariteedi t\u00fckkide arvu (Y) suurendamine suurendab virtuaalse ketta usaldusv\u00e4\u00e4rsust. Mida suurem on Y v\u00e4\u00e4rtus, seda rohkem node klastris v\u00f5ib eba\u00f5nnestuda. Loomulikult v\u00e4hendab pariteedi mahu suurendamine kasulikku mahtu, kuid see on tasu usaldusv\u00e4\u00e4rsuse eest. <\/p>\n

<\/p>\n

Tootlikkuse s\u00f5ltuvus EC skeemidest on peaaegu sirge: mida rohkem \"t\u00fckke\", seda madalam on tootlikkus, siin on vajalik tasakaalustatud l\u00e4henemine. <\/p>\n

<\/p>\n

See l\u00e4henemine v\u00f5imaldab administraatoritel v\u00f5imalikult paindlikult konfigureerida venitatud salvestust. ARDFS-i all olevas bassein on v\u00f5imalik kasutada igasuguseid talitlush\u00e4irete kritiseerimise skeeme ja nende kombinatsioone, mis on samuti meie arvates v\u00e4ga kasulik. <\/p>\n

<\/p>\n

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

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

Tabelist on n\u00e4ha, et isegi k\u00f5ige \"karmim\" EC 8+7 kombinatsioon, mis lubab samal ajal kaotada kuni 7 s\u00f5lme klastris, \"neelab\" v\u00e4hem kasulikku ruumi (1,875 v\u00f5rreldes 2) kui standardne replikatsioon, ja kaitseb 7 korda paremini, mist\u00f5ttu on see kaitsetehnika kuigi keeruline, kuid oluliselt atraktiivsem olukordades, kus on vaja tagada maksimaalset usaldusv\u00e4\u00e4rsust piiratud kettaruumi tingimustes. Samuti tuleb m\u00f5ista, et iga \"pluss\" X v\u00f5i Y juures t\u00e4hendab t\u00e4iendavaid toimetusi tootlikkusele, seega tuleb kolmnurgas usaldusv\u00e4\u00e4rsuse, s\u00e4\u00e4stmise ja tootlikkuse vahel hoolikalt valida. Just seet\u00f5ttu p\u00fchendame eraldi artikli kaugseadmise kodeerimise m\u00f5\u00f5tmisele.<\/p>\n

<\/p>\n

\"Avaldatud<\/p>\n

<\/p>\n

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

<\/p>\n

ARDFS k\u00e4ivitatakse kohapeal k\u00f5igis klastris olevates s\u00f5lmedes ja s\u00fcnkroniseerib neid oma vahenditega l\u00e4bi eraldatud Ethernet-liideste. Oluline on see, et ARDFS s\u00fcnkroniseerib iseseisvalt mitte ainult andmeid, vaid ka andmete salvestamisega seotud metaandmeid. ARDFS-i arendamise k\u00e4igus uurisime paralleelselt mitmeid olemasolevaid lahendusi ja avastasime, et paljuski s\u00fcnkroniseerivad nad failis\u00fcsteemi metaandmeid v\u00e4liste jaotatud andmebaaside kaudu, mida kasutame ka s\u00fcnkroniseerimiseks, kuid ainult seadistuste, mitte failis\u00fcsteemi metaandmete osas (sellest ja teistest seotud alams\u00fcsteemidest j\u00e4rgmises artiklis). <\/p>\n

<\/p>\n

Metaandmete s\u00fcnkroniseerimine failis\u00fcsteemi koos v\u00e4lise andmebaasihalduriga on k\u00fcll toimiv lahendus, kuid siis s\u00f5ltuks ARDFS-is hoitavate andmete j\u00e4rjepidevus v\u00e4lisest andmebaasihaldurist ning selle k\u00e4itumisest (mis, tuleb t\u00f5deda, on kapriisilne), mis meie arvates on halb. Miks? Kui failis\u00fcsteemi metainformatsioon kahjustub, v\u00f5ivad ka failis\u00fcsteemi andmed \u00f6elda \"head aega\", seega otsustasime minna keerulisemat, kuid usaldusv\u00e4\u00e4rsemat teed. <\/p>\n

<\/p>\n

Meie l\u00f5ime ARDFS-i jaoks metainformatsiooni s\u00fcnkroniseerimise alams\u00fcsteemi iseseisvalt ning see toimib t\u00e4ielikult s\u00f5ltumatult k\u00fclgnevate alams\u00fcsteemide tegevusest. 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, kuid kas see on t\u00f5esti nii, n\u00e4itab aeg. Lisaks, sellise l\u00e4henemisega tekib t\u00e4iendav eelis. ARDFS-i saab kasutada iseseisvalt vAIR-st, lihtsalt kui laialt levinud andmesalvestust, millega me kindlasti tulevastes toodetes edasi kasutame.<\/p>\n

<\/p>\n

Sellega, et oleme ARDFS-i v\u00e4lja t\u00f6\u00f6tanud, oleme saanud paindliku ja usaldusv\u00e4\u00e4rse failis\u00fcsteemi, mis pakub valikut, kus saab v\u00e4hendada mahtu v\u00f5i panustada k\u00f5ike j\u00f5udlusse, v\u00f5i teha salvestusruum \u00fclialti usaldusv\u00e4\u00e4rseks m\u00f5\u00f5duka hinna eest, kuid v\u00e4hendades j\u00f5udlusn\u00f5udeid. <\/p>\n

<\/p>\n

Koos lihtsa litsentsimise poliitika ja paindliku tarnemudeliga (enne v\u00e4lja \u00f6eldes, litsentsitakse vAIR s\u00f5lmede j\u00e4rgi ja tarnitakse kas tarkvarana v\u00f5i PAK-ina) v\u00f5imaldab see lahendust t\u00e4pselt kohandada erinevate klientide n\u00f5udmistega ja hiljem seda tasakaalu lihtsalt s\u00e4ilitada. <\/p>\n

<\/p>\n

Kellele seda imet vaja on?<\/h2>\n

<\/p>\n

\u00dchelt poolt v\u00f5ib \u00f6elda, et turul on juba m\u00e4ngijaid, kellel on t\u00f5sised lahendused h\u00fcperkonvergeeritud valdkonnas, kuhu me siis sisuliselt tungime. Tundub, et see v\u00e4ide on \u00f5ige, KUID\u2026<\/p>\n

<\/p>\n

Teiselt poolt, minnes \"v\u00e4lja l\u00f5pudesse\" ja suheldes klientidega, n\u00e4eme meie ja meie partnerid, et asi pole sugugi nii. H\u00fcperkonvergeeritud lahenduste jaoks on palju \u00fclesandeid, kus inimesed ei teadnud lihtsalt, et selliseid lahendusi on olemas, kus see tundus kallis, kus alternatiivsete lahenduste testimine l\u00e4ks kehvasti, ja kus pidavad isegi ostmist keelduma, kuna sanktsioonid. \u00dches\u00f5naga, v\u00e4li osutus harimata maaks, seega l\u00e4ksime seda \u00fcles t\u00f5stma))). <\/p>\n

<\/p>\n

Millal on andmesalvestus parem kui h\u00fcperkonvergeeritud s\u00fcsteem?<\/h3>\n

<\/p>\n

T\u00f6\u00f6tades turuga k\u00fcsitakse meid sageli, millal on parem kasutada klassikalist skeemi SAN-iga ja millal h\u00fcperkonvergeerivaid lahendusi? Paljud ettev\u00f5tted, kes toodavad h\u00fcperkonvergeeritud lahendusi (eriti need, kelle portfellis ei ole SAN-e), \u00fctlevad: \"SAN on oma aja \u00fcle elanud, ainult h\u00fcperkonvergeeritud!\" See on julge v\u00e4ide, kuid see ei peegelda t\u00e4ielikult reaalsust. <\/p>\n

<\/p>\n

T\u00f5de on see, et SAN-turg t\u00f5epoolest liigub h\u00fcperkonvergeerivate ja sarnaste lahenduste suunas, kuid alati on olemas \"aga\".<\/p>\n

<\/p>\n

Esiteks, rajatud andmekeskuseid ja IT-infrastruktuure klassikalise skeemi alusel SAN-iga ei saa niisama lihtsalt \u00fcmber ehitada, seega nende infrastruktuuride moderniseerimine ja t\u00e4iendamine on veel 5\u20137 aastat kestnud p\u00e4rand.<\/p>\n

<\/p>\n

Teiseks, enamiku infrastruktuuride, mis praegu rajatakse (silmas peetakse Venemaad), aluseks on klassikaline skeem SAN-iga. Ja mitte sellep\u00e4rast, et inimesed ei tea h\u00fcperkonvergeeritest, vaid kuna h\u00fcperkonvergeeritud turg on uus, lahendused ja standardid ei ole veel paika loksunud, IT-spetsialistid pole veel koolitatud, kogemusi on v\u00e4he ja andmekeskuseid tuleb rajada siin ja n\u00fc\u00fcd. See tendents kestab veel 3\u20135 aastat (ja siis j\u00e4\u00e4b j\u00e4lle p\u00e4rand, vt punkt 1).<\/p>\n

<\/p>\n

Kolmandaks, puhas tehniline piirang v\u00e4ikeste 2 millisekundiliste viivitustega kirjutamisel (loomulikult, arvestamata kohalike vahem\u00e4lusid), mis on hind jagatud salvestuse eest. <\/p>\n

<\/p>\n

Ja \u00e4rgem unustagem suurte f\u00fc\u00fcsiliste serverite kasutamist, mis eelistavad vertikaalselt skaleerimist diskis\u00fcsteemi.<\/p>\n

<\/p>\n

On palju vajalikke ja populaarseid \u00fclesandeid, kus SAN k\u00e4itub paremini kui h\u00fcperkonvergeeritud lahendused. Meiga ei n\u00f5ustu kindlasti need tootjad, kelle tooteportfellis ei ole SAN-e, kuid oleme valmis p\u00f5hjalikult vaidlema. Loomulikult, kui m\u00f5lemaid tooteid arendavad, teeme \u00fchel tulevasest avaldamisest kindlasti SAN-i ja h\u00fcperkonvergeeritud lahenduste v\u00f5rdluse, kus selgelt n\u00e4itame, millistes tingimustes on kumbki parem.<\/p>\n

<\/p>\n

Kus h\u00fcperkonvergeeritud lahendused t\u00f6\u00f6tavad SAN-ist paremini?<\/h3>\n

<\/p>\n

Eelnevate punktide p\u00f5hjal saab teha kolm ilmset j\u00e4reldust: <\/p>\n

<\/p>\n

    \n
  1. Kohas, kus t\u00e4iendavad 2 millisekundilised viivitused kirjutamisel, mis tekivad igas tootmisprotsessis (praegu ei r\u00e4\u00e4gi me s\u00fcnteetilistest katsetest, s\u00fcnteetiliste testide puhul on v\u00f5imalik n\u00e4idata ka nanosekundeid), on mitte kriitilised, sobib h\u00fcperkonvergeeritud lahendus.<\/li>\n
  2. Seal, kus f\u00fc\u00fcsiliste serverite koormust on v\u00f5imalik muuta paljude v\u00e4ikeste virtuaalsete serverite vahel ja jagada seda node\u2019ide vahel, sinna sobib h\u00fcperkonvergeeritud lahendus h\u00e4sti.<\/li>\n
  3. Seal, kus horisontaalne skaleerimine on olulisem kui vertikaalne, sobivad GKS suurep\u00e4raselt.<\/li>\n<\/ol>\n

    <\/p>\n

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

    <\/p>\n

      \n
    1. K\u00f5ik standard infrastruktuuri teenused (kataloogiteenused, e-post, dokumendihaldus, failiserverid, v\u00e4ikesed v\u00f5i keskmised ERP ja BI s\u00fcsteemid jne). Me nimetame seda \"\u00fcldised arvutused\". <\/li>\n
    2. Kliendipoolsete infrastruktuuride jaoks, kus on vajalik kiire ja standardiseeritud horisontaalne laienemine ning lihtne suure arvu virtuaalmasinate loomine.<\/li>\n
    3. Infrastruktuur virtuaalsetele t\u00f6\u00f6lauale<\/a> (VDI), kus k\u00e4ivitatakse palju v\u00e4ikeseid kasutajate virtuaalmasinaid, mis ujuvad \u00fchtlases klastris.<\/li>\n
    4. Filiaalide v\u00f5rgud, kus igas filiaalis on vaja standardset, talitlush\u00e4irete kindlat, kuid samas odavat infrastruktuuri 15-20 virtuaalmasina jaoks.<\/li>\n
    5. Igasugused jaotatud arvutused (nt big data teenused). Seal, kus koormus ei liberaalse v\u00e4lja, vaid laieneb. <\/li>\n
    6. Testimiskeskkonnad, kus on lubatud v\u00e4iksed viivitused, kuid on eelarvepiirangud, kuna need on testid.<\/li>\n<\/ol>\n

      <\/p>\n

      Praegusel hetkel oleme just nende \u00fclesannete jaoks v\u00e4lja t\u00f6\u00f6tanud AERODISK vAIR ja keskendume neile (kuni praeguse edukuseni). V\u00f5ib-olla see peagi muutub, kuna maailm ei seisa paigal.<\/p>\n

      <\/p>\n

      Nii et\u2026<\/h3>\n

      <\/p>\n

      Sellega on esimene osa suurest artiklite ts\u00fcklist l\u00f5petatud, j\u00e4rgmises artiklis r\u00e4\u00e4gime lahenduse arhitektuurist ja kasutatud komponentidest.<\/p>\n

      <\/p>\n

      Oleme avatud k\u00fcsimustele, ettepanekutele ja konstruktiivsetele vaidlustele.<\/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\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\u00fcperkonvergeeritud lahendus AERODISK vAIR. Alus - failis\u00fcsteem ARDFS | ProHoster","description":"","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: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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}