{"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\/sv\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"Hyperkonvergerande l\u00f6sning AERODISK vAIR. Grunden \u00e4r filsystemet ARDFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Hej, l\u00e4sare av Habr. Med den h\u00e4r artikeln inleder vi en serie som kommer att ber\u00e4tta om v\u00e5rt utvecklade hyperkonvergerande system AERODISK vAIR. Vi ville f\u00f6rst i denna artikel ber\u00e4tta allt om allt, men systemet \u00e4r ganska komplext, s\u00e5 vi kommer att \u00e4ta elefanten bit f\u00f6r bit. <\/p>\n

<\/p>\n

Vi b\u00f6rjar ber\u00e4ttelsen med historien om skapandet av systemet, f\u00f6rdjupar oss i filsystemet ARDFS, som \u00e4r grunden f\u00f6r vAIR, och resonerar lite kring hur denna l\u00f6sning positioneras p\u00e5 den ryska marknaden. <\/p>\n

<\/p>\n

I kommande artiklar kommer vi att g\u00e5 mer i detalj p\u00e5 olika arkitekturkomponenter (kluster, hypervisor, lastbalanserare, \u00f6vervakningssystem osv.), installationsprocessen, ta upp licensieringsfr\u00e5gor, s\u00e4rskilt visa kraschtester och sj\u00e4lvklart skriva om belastningstestning och sizing. Vi kommer ocks\u00e5 att \u00e4gna en artikel \u00e5t community-versionen av vAIR.<\/p>\n

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

\u00c4r AERODISK en historia om lagringssystem? Eller varf\u00f6r b\u00f6rjade vi \u00f6verhuvudtaget arbeta med hyperkonvergens?<\/h2>\n

<\/p>\n

Till en b\u00f6rjan kom id\u00e9n att skapa v\u00e5r egen hyperkonvergens n\u00e5gon g\u00e5ng runt 2010. D\u00e5 fanns det varken AERODISK eller liknande l\u00f6sningar (kommersiella paketl\u00f6sningar f\u00f6r hyperkonvergens) p\u00e5 marknaden. V\u00e5rt m\u00e5l var f\u00f6ljande: fr\u00e5n en upps\u00e4ttning servrar med lokala diskar, sammankopplade med interconnect via Ethernet-protokollet, beh\u00f6vde vi skapa en distribuerad lagring och samtidigt k\u00f6ra virtuella maskiner och ett programn\u00e4tverk. Allt detta m\u00e5ste realiseras utan lagringssystem (eftersom vi helt enkelt inte hade pengar f\u00f6r lagringssystem och dess tillbeh\u00f6r, och vi hade \u00e4nnu inte uppfunnit v\u00e5rt eget lagringssystem).<\/p>\n

<\/p>\n

Vi testade m\u00e5nga open source-l\u00f6sningar och lyckades faktiskt l\u00f6sa uppgiften, men l\u00f6sningen var v\u00e4ldigt komplex och sv\u00e5r att \u00e5terupprepa. Dessutom var det en l\u00f6sning av typen \"Fungerar? R\u00f6r inte!\". S\u00e5 efter att ha l\u00f6st den uppgiften fortsatte vi inte att vidareutveckla id\u00e9n att f\u00f6rvandla resultatet av v\u00e5rt arbete till en fullst\u00e4ndig produkt. <\/p>\n

<\/p>\n

Efter den h\u00e4ndelsen avvek vi fr\u00e5n denna id\u00e9, men vi k\u00e4nde fortfarande att uppgiften var helt l\u00f6sbar, och nyttan av en s\u00e5dan l\u00f6sning var mer \u00e4n uppenbar. De HCI-produkter fr\u00e5n utl\u00e4ndska f\u00f6retag som kom senare bekr\u00e4ftade bara den k\u00e4nslan. <\/p>\n

<\/p>\n

D\u00e4rf\u00f6r \u00e5terv\u00e4nde vi i mitten av 2016 till denna uppgift inom ramen f\u00f6r skapandet av en fullt fungerande produkt. Vid den tiden hade vi inga relationer med investerare, s\u00e5 vi var tvungna att k\u00f6pa utvecklingsst\u00e4ll f\u00f6r v\u00e5ra begr\u00e4nsade pengar. Efter att ha letat p\u00e5 Avito efter begagnade servrar och switchar satte vi ig\u00e5ng.<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Huvuduppgiften i b\u00f6rjan var att skapa v\u00e5rt eget, om \u00e4n enkla, filsystem som skulle kunna automatiskt och j\u00e4mnt f\u00f6rdela data i form av virtuella block p\u00e5 ett n-antal noder i klustret, som var anslutna via Ethernet. Samtidigt skulle FS fungera bra och enkelt kunna skalas samt vara oberoende av angr\u00e4nsande system, det vill s\u00e4ga vara separerbart fr\u00e5n vAIR i form av \"bara ett lagringssystem\".<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Den f\u00f6rsta konceptet av vAIR<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Vi valde medvetet att avst\u00e5 fr\u00e5n att anv\u00e4nda f\u00e4rdiga open source-l\u00f6sningar f\u00f6r att organisera ett distribuerat lagringssystem (ceph, gluster, lustre och liknande) till f\u00f6rm\u00e5n f\u00f6r v\u00e5r egen utveckling, eftersom vi redan hade mycket projektkompetens med dem. Sj\u00e4lvklart \u00e4r dessa l\u00f6sningar utm\u00e4rkta i sig, och innan vi b\u00f6rjade arbeta med Aerodisc genomf\u00f6rde vi flera integrationsprojekt med dem. Men det \u00e4r en sak att l\u00f6sa en specifik uppgift f\u00f6r en kund, utbilda personalen och m\u00f6jligen k\u00f6pa st\u00f6d fr\u00e5n en stor leverant\u00f6r, och helt annat att skapa en l\u00e4tt reproducerbar produkt som kommer att anv\u00e4ndas f\u00f6r olika uppgifter som vi, som leverant\u00f6r, kanske till och med inte vet om. F\u00f6r detta \u00e4ndam\u00e5l var existerande open source-produkter inte l\u00e4mpliga, s\u00e5 vi beslutade att utveckla ett distribuerat filsystem sj\u00e4lva.
\nTv\u00e5 \u00e5r senare n\u00e5dde vi genom insatserna fr\u00e5n flera utvecklare (som kombinerade arbetet med vAIR med arbetet med klassiska lagringssystemet Engine) ett visst resultat.<\/p>\n

<\/p>\n

Till 2018 hade vi skrivit ett enklaste filsystem och kompletterat det med n\u00f6dv\u00e4ndig kringutrustning. Systemet samlade fysiska (lokala) diskar fr\u00e5n olika servrar \u00f6ver intern interconnect i en platt pool och \"delade\" dem i virtuella block, fr\u00e5n vilka blocken skapades blockenheter med en viss grad av felmotst\u00e5nd, p\u00e5 vilka virtuella maskiner skapades och k\u00f6rdes med hj\u00e4lp av hypervisor KVM. <\/p>\n

<\/p>\n

Vi lade inte s\u00e5 mycket tid p\u00e5 namnet p\u00e5 filsystemet och kallade det kort och gott ARDFS (gissa vad det st\u00e5r f\u00f6r))<\/p>\n

<\/p>\n

Denna prototyp s\u00e5g bra ut (inte visuellt, f\u00f6rst\u00e5s, det fanns ingen visuell design d\u00e5) och visade goda prestanda och skalbarhet. Efter det f\u00f6rsta verkliga resultatet gick vi vidare med detta projekt, organiserade en komplett utvecklingsmilj\u00f6 och ett separat team som bara arbetade med vAIR.<\/p>\n

<\/p>\n

Precis vid den tiden mognade den \u00f6vergripande arkitekturen av l\u00f6sningen, som fortfarande inte genomg\u00e5tt n\u00e5gra betydande f\u00f6r\u00e4ndringar.<\/p>\n

<\/p>\n

L\u00e5t oss dyka ner i filsystemet ARDFS<\/h2>\n

<\/p>\n

ARDFS \u00e4r grunden f\u00f6r vAIR, som erbjuder distribuerad, felfri lagring av data f\u00f6r hela klustret. En av (men inte den enda) utm\u00e4rkande egenskaperna hos ARDFS \u00e4r att den inte anv\u00e4nder n\u00e5gra ytterligare dedikerade servrar<\/a> under meta och styrning. Detta var ursprungligen t\u00e4nkt f\u00f6r att f\u00f6renkla konfigurationen av l\u00f6sningen och f\u00f6r dess tillf\u00f6rlitlighet. <\/p>\n

<\/p>\n

Lagringsstruktur<\/h3>\n

<\/p>\n

Inom alla noder i klustret organiserar ARDFS en logisk pool av hela det tillg\u00e4ngliga diskutrymmet. Det \u00e4r viktigt att f\u00f6rst\u00e5 att en pool inte \u00e4r data eller formaterat utrymme, utan bara en indelning, dvs. alla noder med installerad vAIR som l\u00e4ggs till klustret automatiskt ansluts till den gemensamma ARDFS-poolen och diskinfrastrukturen blir automatiskt gemensam f\u00f6r hela klustret (och tillg\u00e4nglig f\u00f6r framtida datalagring). Detta tillv\u00e4gag\u00e5ngss\u00e4tt g\u00f6r att noder kan l\u00e4ggas till och tas bort i farten utan att ha n\u00e5got st\u00f6rre inflytande p\u00e5 det redan fungerande systemet. Det vill s\u00e4ga, systemet \u00e4r mycket l\u00e4tt att skala \"sten f\u00f6r sten\", genom att l\u00e4gga till eller ta bort noder i klustret efter behov.<\/p>\n

<\/p>\n

\u00d6ver ARDFS-poolen l\u00e4ggs virtuella diskar (lagringsobjekt f\u00f6r virtuella maskiner), som byggs upp av virtuella block p\u00e5 4 megabyte. P\u00e5 de virtuella diskarna lagras data direkt. P\u00e5 niv\u00e5n av virtuella diskar anges ocks\u00e5 en schema f\u00f6r fel tolerans. <\/p>\n

<\/p>\n

Som man redan kan gissa, f\u00f6r att uppn\u00e5 driftss\u00e4kerhet i v\u00e5rt lagringssystem anv\u00e4nder vi inte RAID (Redundant array of independent Disks) konceptet utan RAIN (Redundant array of independent Nodes). Det vill s\u00e4ga, driftss\u00e4kerheten m\u00e4ts, automatiseras och hanteras utifr\u00e5n noder snarare \u00e4n diskar. Sj\u00e4lvklart \u00e4r diskar ocks\u00e5 en lagringsobjekt, de \u00f6vervakas liksom allt annat och man kan utf\u00f6ra alla standardoperationer med dem, inklusive att skapa en lokal h\u00e5rdvaru-RAID, men klustret arbetar med noder. <\/p>\n

<\/p>\n

I en situation d\u00e4r man verkligen vill anv\u00e4nda RAID (till exempel, ett scenario som st\u00f6der flera fel p\u00e5 sm\u00e5 kluster) finns det inget som hindrar att man anv\u00e4nder lokala RAID-kontroller och ovanp\u00e5 bygger ett distribuerat lagringssystem med RAIN-arkitektur. S\u00e5dana scenarier \u00e4r fullt livskraftiga och st\u00f6djs av oss, d\u00e4rf\u00f6r kommer vi att ber\u00e4tta om dem i artikeln om typiska anv\u00e4ndningsscenario f\u00f6r vAIR.<\/p>\n

<\/p>\n

Lagringssystem f\u00f6r driftss\u00e4kerhet<\/h3>\n

<\/p>\n

Det kan finnas tv\u00e5 typer av driftss\u00e4kerhetsscheman f\u00f6r virtuella diskar i vAIR:<\/p>\n

<\/p>\n

1) Replikationsfaktor eller helt enkelt replikering \u2013 denna metod f\u00f6r driftss\u00e4kerhet \u00e4r enkel \"som en pinne och ett rep\". Den inneb\u00e4r synkron replikering mellan noder med en faktor av 2 (2 kopior per kluster) eller 3 (3 kopior, respektive). RF-2 g\u00f6r att den virtuella disken kan klara av ett fel p\u00e5 en nod i klustret, men \"\u00e4ter upp\" h\u00e4lften av det nyttiga utrymmet, medan RF-3 klarar av tv\u00e5 noder i klustret, men reserverar redan 2\/3 av det nyttiga utrymmet f\u00f6r sina behov. Detta schema p\u00e5minner mycket om RAID-1, vilket inneb\u00e4r att den virtuella disken konfigurerad i RF-2 \u00e4r motst\u00e5ndskraftig mot ett fel p\u00e5 vilken som helst av noderna i klustret. I s\u00e5 fall kommer det inte att vara n\u00e5got fel p\u00e5 data och \u00e4ven I\/O kommer inte att stoppas. N\u00e4r den felande noden \u00e5terkommer till drift b\u00f6rjar automatisk \u00e5terst\u00e4llning\/synkronisering av data. <\/p>\n

<\/p>\n

Nedan f\u00f6ljer exempel p\u00e5 datadistribution f\u00f6r RF-2 och RF-3 i normalsituationer och vid fel.<\/p>\n

<\/p>\n

Vi har en virtuell maskin med 8 MB unika (anv\u00e4ndbara) data som k\u00f6rs p\u00e5 4 noder vAIR. Det \u00e4r uppenbart att det i verkligheten knappast kommer att vara s\u00e5 lite, men f\u00f6r en skiss som \u00e5terspeglar logiken av ARDFS \u00e4r detta exempel mest begripligt. AB \u2013 dessa \u00e4r virtuella block p\u00e5 4 MB som inneh\u00e5ller unika data fr\u00e5n den virtuella maskinen. Vid RF-2 skapas tv\u00e5 kopior av dessa block A1+A2 och B1+B2, respektive. Dessa block \"distribueras\" \u00f6ver noderna, f\u00f6r att undvika \u00f6verlappning av samma data p\u00e5 en nod, det vill s\u00e4ga att kopian A1 inte kommer att finnas p\u00e5 samma nod som kopia A2. Detsamma g\u00e4ller f\u00f6r B1 och B2.<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Vid ett avbrott p\u00e5 en av noderna (till exempel nod nr 3 d\u00e4r kopia B1 finns) aktiveras denna kopia automatiskt p\u00e5 den nod d\u00e4r det inte finns en kopia av sin kopia (det vill s\u00e4ga kopia B2). <\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

D\u00e4rmed kommer den virtuella disken (och VM:n, i sin tur) l\u00e4tt att \u00f6verleva ett avbrott p\u00e5 en nod i RF-2-systemet.<\/p>\n

<\/p>\n

Replikeringsschemat, trots sin enkelhet och tillf\u00f6rlitlighet, lider av samma problem som RAID1 - lite anv\u00e4ndbart utrymme.<\/p>\n

<\/p>\n

2) Erasure coding eller raderande kodning (\u00e4ven k\u00e4nt som \"\u00f6verskottskodning\", \"st\u00e4rande kodning\" eller \"redundanskod\") finns just f\u00f6r att l\u00f6sa ovanst\u00e5ende problem. EC \u2013 ett \u00f6verskottsprogram som s\u00e4kerst\u00e4ller h\u00f6g datatillg\u00e4nglighet med l\u00e4gre kostnad f\u00f6r lagringsutrymme j\u00e4mf\u00f6rt med replikation. Mekanismen fungerar p\u00e5 liknande s\u00e4tt som RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Vid kodning delar EC-processen det virtuella blocket (som standard 4 MB) i flera mindre \"datafraktioner\" beroende p\u00e5 EC-schemat (till exempel delar 2+1-schemat varje 4 MB-block i 2 fraktioner om 2 MB). D\u00e4refter genererar processen \"paritetsfraktioner\" av storlek som inte \u00f6verstiger en av de tidigare delade delarna. Vid avkodning genererar EC de saknade fraktionerna genom att l\u00e4sa \"\u00f6verlevande\" data i hela klustret. <\/p>\n

<\/p>\n

Till exempel kan en virtuell disk med EC-schema 2+1, implementerad p\u00e5 4 noder i ett kluster, utan problem hantera ett avbrott p\u00e5 en nod i klustret, precis som RF-2. H\u00e4r kommer overheaden att vara l\u00e4gre, s\u00e4rskilt eftersom nyttolasten f\u00f6r RF-2 \u00e4r 2, medan den f\u00f6r EC 2+1 \u00e4r 1,5. <\/p>\n

<\/p>\n

F\u00f6r att f\u00f6rklara det enklare handlar det om att det virtuella blocket delas upp i 2-8 (varf\u00f6r fr\u00e5n 2 till 8 se nedan) \"bitar\", och f\u00f6r dessa bitar ber\u00e4knas \"paritetsbitar\" av motsvarande storlek. <\/p>\n

<\/p>\n

Som ett resultat f\u00f6rdelas data och paritet j\u00e4mnt \u00f6ver alla noder i klustret. Precis som vid replikering f\u00f6rdelar ARDFS automatiskt data \u00f6ver noderna s\u00e5 att identiska data (datacopy och dess paritet) inte lagras p\u00e5 samma nod, f\u00f6r att utesluta risken att f\u00f6rlora data p\u00e5 grund av att data och dess paritet pl\u00f6tsligt skulle finnas p\u00e5 en lagringsnod som g\u00e5r s\u00f6nder. <\/p>\n

<\/p>\n

Nedan ett exempel med samma virtuella maskin p\u00e5 8 MB och 4 noder, men med EC 2+1. <\/p>\n

<\/p>\n

Block A and B are divided into two pieces of 2 MB each (the two because 2+1), meaning A1+A2 and B1+B2. Unlike a replica, A1 is not a copy of A2; it is a virtual block A divided into two parts, and the same goes for block B. In total, we have two sets of 4MB, each containing two two-megabyte pieces. Next, for each of these sets, parity is computed, with a volume not exceeding one piece (i.e., 2 MB), resulting in an additional +2 pieces of parity (A-P and B-P). Thus, we have 4\u00d72 data + 2\u00d72 parity.<\/p>\n

<\/p>\n

D\u00e4refter \"sprider\" bitarna ut sig \u00f6ver noderna s\u00e5 att data inte \u00f6verlappar med sin paritet. D.v.s. A1 och A2 kommer inte att finnas p\u00e5 samma nod som A-P.<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

I h\u00e4ndelse av att en nod (l\u00e5tom oss s\u00e4ga den tredje) g\u00e5r ner, kommer den f\u00f6rlorade blocket B1 automatiskt att \u00e5terst\u00e4llas fr\u00e5n pariteten B-P, som lagras p\u00e5 nod nummer 2, och aktiveras p\u00e5 noden d\u00e4r B-pariteten inte finns, dvs delen B-P. I detta exempel \u00e4r det nod nummer 1.<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Jag \u00e4r s\u00e4ker p\u00e5 att l\u00e4saren har en fr\u00e5ga:<\/p>\n

<\/p>\n

\"Allt du har beskrivit har l\u00e4nge realiserats av konkurrenter och i open source-l\u00f6sningar, vad \u00e4r skillnaden med er implementation av EC i ARDFS?\"<\/p><\/blockquote>\n

Och vidare kommer intressanta funktioner av ARDFS.<\/p>\n

<\/p>\n

Erasure coding med fokus p\u00e5 flexibilitet<\/h3>\n

<\/p>\n

Vi har initialt f\u00f6rutsett ett ganska flexibelt EC-schema X+Y, d\u00e4r X \u00e4r ett tal mellan 2 och 8, och Y \u00e4r ett tal mellan 1 och 8, men alltid mindre \u00e4n eller lika med X. Detta schema \u00e4r avsett f\u00f6r flexibilitet. \u00d6kningen av antalet data bitar (X) som den virtuella blocket delas upp i minskar overheadkostnaderna, det vill s\u00e4ga \u00f6kar det anv\u00e4ndbara utrymmet.
\n\u00c5 andra sidan \u00f6kar antalet paritetsbitar (Y) tillf\u00f6rlitligheten av den virtuella disken. Ju h\u00f6gre v\u00e4rde p\u00e5 Y, desto fler noder i klustret kan g\u00e5 ner. Sj\u00e4lvklart minskar \u00f6kning av paritetsvolymen det anv\u00e4ndbara lagringsutrymmet, men detta \u00e4r ett pris f\u00f6r tillf\u00f6rlitlighet. <\/p>\n

<\/p>\n

Prestandan beror n\u00e4stan direkt p\u00e5 EC-schema: ju fler \"bitar\", desto l\u00e4gre prestanda, h\u00e4r kr\u00e4vs en balanserad syn. <\/p>\n

<\/p>\n

Denna metod g\u00f6r det m\u00f6jligt f\u00f6r administrat\u00f6rer att konfigurera det distribuerade lagret maximalt flexibelt. Inom ARDFS-poolen kan man anv\u00e4nda vilken som helst av redundansscheman och deras kombinationer, vilket vi ocks\u00e5 tycker \u00e4r mycket anv\u00e4ndbart. <\/p>\n

<\/p>\n

Nedan f\u00f6ljer en j\u00e4mf\u00f6relsetabell mellan flera (inte alla m\u00f6jliga) RF- och EC-scheman.<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Tabellen visar att \u00e4ven den mest \"extrema\" kombinationen EC 8+7, som till\u00e5ter f\u00f6rlust av upp till 7 noder i klustret samtidigt, \"\u00e4krar\" mindre anv\u00e4ndbart utrymme (1,875 mot 2) \u00e4n standardreplikering, och skyddar sju g\u00e5nger b\u00e4ttre, vilket g\u00f6r denna skyddsmekanism, \u00e4ven om den \u00e4r mer komplex, betydligt mer attraktiv i situationer d\u00e4r maximal tillf\u00f6rlitlighet beh\u00f6ver s\u00e4kerst\u00e4llas under brist p\u00e5 diskutrymme. Det m\u00e5ste dock f\u00f6rst\u00e5s att varje \"plus\" till X eller Y medf\u00f6r en extra prestandakostnad, s\u00e5 i triangel mellan tillf\u00f6rlitlighet, kostnadsbesparing och prestanda m\u00e5ste valet g\u00f6ras mycket noggrant. Av denna anledning kommer vi att \u00e4gna en separat artikel \u00e5t storlekning av borttagningskodning.<\/p>\n

<\/p>\n

\"Hyperkonvergerande<\/p>\n

<\/p>\n

Tillf\u00f6rlitlighet och autonomi i filsystemet<\/h3>\n

<\/p>\n

ARDFS k\u00f6rs lokalt p\u00e5 alla noder i klustret och synkroniserar med sina egna medel genom dedikerade Ethernet-gr\u00e4nssnitt. En viktig punkt \u00e4r att ARDFS sj\u00e4lv synkroniserar inte bara data, utan \u00e4ven metadata relaterade till lagring. Under arbetet med ARDFS studerade vi parallellt ett antal befintliga l\u00f6sningar och uppt\u00e4ckte att m\u00e5nga g\u00f6r synkronisering av metadata i filsystemet med hj\u00e4lp av en extern distribuerad DBMS, som vi ocks\u00e5 anv\u00e4nder f\u00f6r synkronisering, men endast f\u00f6r konfigurationer, inte metadata i FS (om detta och andra angr\u00e4nsande subsystem i n\u00e4sta artikel). <\/p>\n

<\/p>\n

Synkronisering av metadata f\u00f6r filsystemet med hj\u00e4lp av en extern databasl\u00f6sning \u00e4r f\u00f6rst\u00e5s en fungerande metod, men d\u00e5 skulle datakonsistensen som lagras p\u00e5 ARDFS bero p\u00e5 den externa databasen och dess beteende (och den, ska vi s\u00e4ga, \u00e4r en lite knepig dam), vilket vi anser \u00e4r d\u00e5ligt. Varf\u00f6r? Om metadata f\u00f6r filsystemet skulle skadas, skulle \u00e4ven sj\u00e4lva data f\u00f6r filsystemet s\u00e4ga \"adj\u00f6\", d\u00e4rf\u00f6r beslutade vi oss f\u00f6r att v\u00e4lja en mer komplex men p\u00e5litlig v\u00e4g. <\/p>\n

<\/p>\n

Vi har sj\u00e4lva utvecklat en metadata-synkroniseringssubsystem f\u00f6r ARDFS, och den fungerar helt oberoende av angr\u00e4nsande subsystem. D.v.s. inga andra subsystem kan skada ARDFS-data. Vi anser att detta \u00e4r den mest p\u00e5litliga och korrekta v\u00e4gen, och om det verkligen \u00e4r s\u00e5 kommer tiden att visa. Dessutom medf\u00f6r detta tillv\u00e4gag\u00e5ngss\u00e4tt en ytterligare f\u00f6rdel. ARDFS kan anv\u00e4ndas oberoende av vAIR, helt enkelt som en utstr\u00e4ckt lagringsl\u00f6sning, vilket vi utan tvekan kommer att dra nytta av i framtida produkter.<\/p>\n

<\/p>\n

Som ett resultat av att vi har utvecklat ARDFS har vi f\u00e5tt ett flexibelt och p\u00e5litligt filsystem som ger m\u00f6jlighet att spara p\u00e5 kapaciteten eller satsa allt p\u00e5 prestanda, eller att g\u00f6ra lagringsl\u00f6sningen supers\u00e4ker till ett rimligt pris men med minskade prestandakrav. <\/p>\n

<\/p>\n

Tillsammans med en enkel licenspolicy och en flexibel distributionsmodell (f\u00f6r att f\u00f6rskjuta, licensieras vAIR per nod och levereras antingen som mjukvara eller som en paketl\u00f6sning) g\u00f6r detta att man kan skr\u00e4ddarsy l\u00f6sningen mycket noggrant f\u00f6r olika kundbehov, och sedan l\u00e4tt uppr\u00e4tth\u00e5lla denna balans. <\/p>\n

<\/p>\n

Vem beh\u00f6ver detta underverk?<\/h2>\n

<\/p>\n

\u00c5 ena sidan kan man s\u00e4ga att det redan finns akt\u00f6rer p\u00e5 marknaden med seri\u00f6sa l\u00f6sningar inom hyperkonvergens, och vad \u00e4r det vi egentligen g\u00f6r? Det verkar som om detta p\u00e5st\u00e5ende \u00e4r sant, MEN...<\/p>\n

<\/p>\n

\u00c5 andra sidan, n\u00e4r vi g\u00e5r \"ut i f\u00e4lt\" och pratar med kunder ser vi, liksom v\u00e5ra partners, att s\u00e5 inte \u00e4r fallet. Det finns m\u00e5nga behov f\u00f6r hyperkonvergens; p\u00e5 vissa st\u00e4llen visste folk bara inte att s\u00e5dana l\u00f6sningar existerade, p\u00e5 andra st\u00e4llen verkade det dyrt, i vissa fall har alternativl\u00f6sningar misslyckats, och i andra fall \u00e4r ink\u00f6p helt enkelt f\u00f6rbjudna p\u00e5 grund av sanktioner. Det hela visade sig vara en obearbetad mark, s\u00e5 vi beslutade oss f\u00f6r att bryta ny mark))). <\/p>\n

<\/p>\n

N\u00e4r \u00e4r HCI b\u00e4ttre \u00e4n SDS?<\/h3>\n

<\/p>\n

I arbetet med marknaden f\u00e5r vi ofta fr\u00e5gan om n\u00e4r man b\u00e4st b\u00f6r anv\u00e4nda den klassiska modellen med lagringssystem, och n\u00e4r man ska \u00f6verg\u00e5 till hyperkonvergerande l\u00f6sningar? M\u00e5nga f\u00f6retag som tillverkar HCI (s\u00e4rskilt de utan lagringssystem i sitt sortiment) s\u00e4ger: \"Lagringssystemets tid \u00e4r f\u00f6rbi, hyperkonvergerande only!\". Detta \u00e4r ett dj\u00e4rvt uttalande, men det speglar inte helt verkligheten. <\/p>\n

<\/p>\n

\u00c4rligt talat \u00e4r marknaden f\u00f6r lagringssystem verkligen p\u00e5 v\u00e4g mot hyperkonvergerade l\u00f6sningar, men det finns alltid en \"men\".<\/p>\n

<\/p>\n

F\u00f6r det f\u00f6rsta kan inte befintliga datacenter och IT-infrastrukturer, som byggts efter den klassiska modellen med lagringssystem, enkelt omstruktureras, s\u00e5 uppgradering och utbyggnad av s\u00e5dana infrastrukturer \u00e4r ett arv som kommer att finnas kvar i 5-7 \u00e5r till.<\/p>\n

<\/p>\n

F\u00f6r det andra byggs de infrastrukturer som skapas just nu (med avseende p\u00e5 Ryssland) mestadels enligt den klassiska modellen med anv\u00e4ndning av lagringssystem, inte f\u00f6r att m\u00e4nniskor inte k\u00e4nner till hyperkonvergerande l\u00f6sningar, utan f\u00f6r att marknaden f\u00f6r hyperkonvergerande l\u00f6sningar \u00e4r ny, l\u00f6sningar och standarder har \u00e4nnu inte stabiliserats, IT-specialister \u00e4r fortfarande inte utbildade, erfarenheten \u00e4r begr\u00e4nsad, och datacenter m\u00e5ste byggas h\u00e4r och nu. Denna trend kommer att best\u00e5 i ytterligare 3-5 \u00e5r (plus ett arv, se punkt 1).<\/p>\n

<\/p>\n

F\u00f6r det tredje finns det rent tekniska begr\u00e4nsningar i form av ytterligare sm\u00e5 f\u00f6rdr\u00f6jningar p\u00e5 2 millisekunder vid skrivning (utan att ta h\u00e4nsyn till lokal cache, s\u00e5 klart), som \u00e4r priset f\u00f6r distribuerad lagring. <\/p>\n

<\/p>\n

Och vi f\u00e5r inte gl\u00f6mma anv\u00e4ndningen av stora fysiska servrar, som f\u00f6redrar vertikal skalning av lagringssystemet.<\/p>\n

<\/p>\n

Det finns m\u00e5nga viktiga och popul\u00e4ra uppgifter d\u00e4r lagringssystem fungerar b\u00e4ttre \u00e4n HCI. Sj\u00e4lvklart kommer de tillverkare som inte har lagringssystem i sitt produktutbud inte att h\u00e5lla med oss, men vi \u00e4r beredda att argumentera f\u00f6r v\u00e5r sak. Sj\u00e4lvklart kommer vi, som utvecklare av b\u00e5da produkterna, i en av v\u00e5ra framtida publikationer att g\u00f6ra en j\u00e4mf\u00f6relse mellan lagringssystem och HCI, d\u00e4r vi tydligt visar vilka f\u00f6rh\u00e5llanden som \u00e4r b\u00e4st f\u00f6r respektive l\u00f6sningar.<\/p>\n

<\/p>\n

Och var kommer hyperkonvergerande l\u00f6sningar att fungera b\u00e4ttre \u00e4n lagringssystem?<\/h3>\n

<\/p>\n

Baserat p\u00e5 de ovanst\u00e5ende teserna kan man dra tre uppenbara slutsatser: <\/p>\n

<\/p>\n

    \n
  1. D\u00e4r ytterligare 2 millisekunders f\u00f6rdr\u00f6jning vid skrivning, som stabilt uppst\u00e5r i alla produktionsmilj\u00f6er (nu handlar det inte om syntetiska test, d\u00e4r man kan visa nanosekunder), \u00e4r icke-kritiska, kan hyperkonvergerande l\u00f6sningar passa.<\/li>\n
  2. D\u00e4r belastningen fr\u00e5n stora fysiska servrar kan omvandlas till m\u00e5nga sm\u00e5 virtuella och f\u00f6rdelas \u00f6ver noder, d\u00e4r passar hyperkonvergens bra.<\/li>\n
  3. D\u00e4r horisontell skalning \u00e4r mer prioriterad \u00e4n vertikal, d\u00e4r kommer GKS att fungera utm\u00e4rkt.<\/li>\n<\/ol>\n

    <\/p>\n

    Vilka \u00e4r dessa l\u00f6sningar?<\/h3>\n

    <\/p>\n

      \n
    1. Alla standardinfrastrukturtj\u00e4nster (katalogtj\u00e4nst, e-post, DMS, filservrar, sm\u00e5 eller medelstora ERP och BI-system, mm). Vi kallar detta \"gemensamma ber\u00e4kningar\". <\/li>\n
    2. Infrastrukturen hos molnleverant\u00f6rer d\u00e4r det \u00e4r n\u00f6dv\u00e4ndigt att snabbt och standardiserat skala horisontellt och l\u00e4tt \"sk\u00e4ra\" ett stort antal virtuella maskiner f\u00f6r kunder.<\/li>\n
    3. Infrastruktur virtuella skrivbord<\/a> (VDI), d\u00e4r m\u00e5nga sm\u00e5 anv\u00e4ndarvirtualer startas och fritt \"flyter\" inom en enhetlig kluster.<\/li>\n
    4. Filialn\u00e4tverk d\u00e4r varje filial beh\u00f6ver en standardiserad, redundanta men \u00e4nd\u00e5 kostnadseffektiv infrastruktur av 15-20 virtuella maskiner.<\/li>\n
    5. Vilka distributerade ber\u00e4kningar som helst (s\u00e5som big data-tj\u00e4nster). D\u00e4r belastningen inte g\u00e5r \"ned\u00e5t\", utan \"ut\u00e5t\". <\/li>\n
    6. Testmilj\u00f6er d\u00e4r sm\u00e5 extra f\u00f6rdr\u00f6jningar \u00e4r acceptabla, men det finns budgetbegr\u00e4nsningar eftersom detta \u00e4r tester.<\/li>\n<\/ol>\n

      <\/p>\n

      F\u00f6r tillf\u00e4llet har vi skapat AERODISK vAIR f\u00f6r dessa uppgifter, och vi fokuserar p\u00e5 dem (framg\u00e5ngsrikt hittills). Kanske kommer detta att \u00e4ndras snart, eftersom v\u00e4rlden inte st\u00e5r stilla.<\/p>\n

      <\/p>\n

      S\u00e5\u2026<\/h3>\n

      <\/p>\n

      Den f\u00f6rsta delen av en stor artikelcykel avslutas h\u00e4r, i n\u00e4sta artikel kommer vi att ber\u00e4tta om arkitekturen f\u00f6r l\u00f6sningen och de anv\u00e4nda komponenterna.<\/p>\n

      <\/p>\n

      Vi ser fram emot fr\u00e5gor, f\u00f6rslag och konstruktiva diskussioner.<\/p>\n

      K\u00e4lla: 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\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\udd47Hyperkonvergerande l\u00f6sning AERODISK vAIR. Grunden \u00e4r filsystemet ARDFS | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}