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

\"Hyperkonvergerende<\/p>\n

<\/p>\n

Hej l\u00e6sere af Habr. Med denne artikel \u00e5bner vi en cyklus, der vil fort\u00e6lle om vores udviklede hyperkonvergerede system AERODISK vAIR. Oprindeligt havde vi planlagt at fort\u00e6lle alt om alt i den f\u00f8rste artikel, men systemet er ret komplekst, s\u00e5 vi vil tage det i bidder. <\/p>\n

<\/p>\n

Vi starter fort\u00e6llingen med historien om oprettelsen af systemet, dykker ned i filsystemet ARDFS, som er grundlaget for vAIR, og reflekterer lidt over dette l\u00f8snings positionering p\u00e5 det russiske marked. <\/p>\n

<\/p>\n

I de n\u00e6ste artikler vil vi tale mere detaljeret om de forskellige arkitektoniske komponenter (klynge, hypervisor, belastningsfordeler, overv\u00e5gningssystem osv.), installationsprocessen, vi vil rejse sp\u00f8rgsm\u00e5l om licensering, vise crash tests og selvf\u00f8lgelig skrive om belastningstest og sizing. Vi vil ogs\u00e5 dedikere en separat artikel til community-versionen af vAIR.<\/p>\n

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

AERODISK \u2013 er dette ikke en historie om SAN? Eller hvorfor begyndte vi overhovedet at besk\u00e6ftige os med hyperkonvergens?<\/h2>\n

<\/p>\n

Oprindeligt kom ideen om at skabe vores egen hyperkonvergerede l\u00f8sning til os omkring 2010. Dengang var der hverken AERODISK eller lignende l\u00f8sninger (kommercielle pakkel\u00f8sninger for hyperkonvergerede systemer) p\u00e5 markedet. Vores opgave var f\u00f8lgende: fra et s\u00e6t servere med lokale disks, bundet sammen via interconnect med Ethernet-protokollen, m\u00e5tte der skabes et distribueret lager, hvor virtuelle maskiner og et softwarenetv\u00e6rk kunne k\u00f8re. Alt dette skulle realiseres uden SAN (da vi simpelthen ikke havde penge til SAN og dens tilslutning, og vi havde endnu ikke opfundet vores egen SAN).<\/p>\n

<\/p>\n

Vi pr\u00f8vede mange open source-l\u00f8sninger og l\u00f8ste denne opgave, men l\u00f8sningen var meget kompleks, og det var sv\u00e6rt at gentage den. Desuden var denne l\u00f8sning af typen 'Virker det? Lad det v\u00e6re!'. Derfor, efter vi havde l\u00f8st opgaven, besluttede vi ikke at udvikle ideen om at transformere resultatet af vores arbejde til et fuldgyldigt produkt. <\/p>\n

<\/p>\n

Efter den oplevelse bev\u00e6gede vi os v\u00e6k fra denne id\u00e9, men vi kunne stadig ikke ryste f\u00f8lelsen af, at denne opgave bestemt kunne l\u00f8ses, og at fordelene ved en s\u00e5dan l\u00f8sning var mere end \u00e5benlyse. Senere bekr\u00e6ftede de HCI-produkter fra udenlandske virksomheder denne f\u00f8lelse. <\/p>\n

<\/p>\n

Derfor vendte vi i midten af 2016 tilbage til denne opgave som en del af udviklingen af et fuldt produkt. P\u00e5 det tidspunkt havde vi ikke nogen relationer til investorer, s\u00e5 vi m\u00e5tte k\u00f8be udviklingsstandet for vores egne, ikke s\u00e6rlig store penge. Vi gik i gang med at k\u00f8be brugte servere og switche p\u00e5 Avito.<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

Den prim\u00e6re indledende opgave var at skabe vores egen, omend simple, filsystem, der kunne automatisere og j\u00e6vnt fordele data i form af virtuelle blokke over et n-model klynge, som var interconnectet via Ethernet. Filsystemet skulle desuden v\u00e6re let at skalere og uafh\u00e6ngigt af tilst\u00f8dende systemer, alts\u00e5 kunne ses som 'bare en lagerplads' adskilt fra vAIR.<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

Den f\u00f8rste koncept for vAIR<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

Vi valgte bevidst at undg\u00e5 at bruge eksisterende open source-l\u00f8sninger til at organisere udstrakte lager (ceph, gluster, lustre og lignende) til fordel for vores egen udvikling, da vi allerede havde meget projekt erfaring med dem. Disse l\u00f8sninger er uden tvivl fremragende, og f\u00f8r arbejdet med Aerdisk havde vi allerede implementeret flere integrationsprojekter med dem. Men det er en ting at l\u00f8se en specifik opgave for \u00e9n kunde, tr\u00e6ne personale og m\u00e5ske k\u00f8be support fra en stor leverand\u00f8r, og noget helt andet at skabe et let reproducerbart produkt, der vil blive brugt til forskellige form\u00e5l, som vi som leverand\u00f8r muligvis ikke engang selv kender. For dette form\u00e5l fungerede eksisterende open source-produkter ikke, derfor besluttede vi at udvikle et distribueret filsystem selv.
\nEfter to \u00e5r, med indsatsen fra flere udviklere (som kombinerede arbejdet med vAIR med arbejdet p\u00e5 en klassisk storage system Engine), opn\u00e5ede vi et vist resultat.<\/p>\n

<\/p>\n

I 2018 skrev vi et simpelt filsystem og supplere det med den n\u00f8dvendige indpakning. Systemet samlede fysiske (lokale) diske fra forskellige servere gennem intern interconnection i en flad pulje og 'skar' dem op i virtuelle blokke, hvorefter der blev oprettet blok enheder fra de virtuelle blokke med en eller anden grad af fejltolerance, hvorp\u00e5 der med KVM hypervisoren blev oprettet og k\u00f8rt virtuelle maskiner. <\/p>\n

<\/p>\n

Vi knyttede ikke meget opm\u00e6rksomhed til filsystemets navn og kaldte det lakonisk ARDFS (g\u00e6t selv, hvad det st\u00e5r for))<\/p>\n

<\/p>\n

Denne prototype s\u00e5 godt ud (ikke visuelt, selvf\u00f8lgelig, der var ikke noget visuelt layout dengang) og viste gode resultater med hensyn til ydeevne og skalerbarhed. Efter det f\u00f8rste reelle resultat satte vi projektet i gang, organiserede et fuldt udviklingsmilj\u00f8 og en separat gruppe, der kun arbejdede med vAIR.<\/p>\n

<\/p>\n

Lige p\u00e5 det tidspunkt var den overordnede arkitektur af l\u00f8sningen blevet moden, og den har ikke gennemg\u00e5et nogen v\u00e6sentlige \u00e6ndringer siden.<\/p>\n

<\/p>\n

Lad os dykke ned i filsystemet ARDFS<\/h2>\n

<\/p>\n

ARDFS udg\u00f8r fundamentet for vAIR, som sikrer distribueret fejltolerance til datalagring i hele klyngen. Et af (men ikke det eneste) kendetegn ved ARDFS er, at det ikke bruger nogen yderligere dedikerede servere<\/a> under metafor og administration. Dette blev oprindeligt t\u00e6nkt for at forenkle l\u00f8sningens konfiguration og for dens p\u00e5lidelighed. <\/p>\n

<\/p>\n

Lagringsstruktur<\/h3>\n

<\/p>\n

Inden for alle noder i klyngen organiserer ARDFS et logisk pulje af alt tilg\u00e6ngeligt diskplads. Det er vigtigt at forst\u00e5, at puljen endnu ikke er data eller formateret plads, men bare en markering, dvs. alle noder med installeret vAIR, der tilf\u00f8jes til klyngen, tilf\u00f8jes automatisk til den f\u00e6lles ARDFS-pulje, og diskressourcerne bliver automatisk f\u00e6lles for hele klyngen (og tilg\u00e6ngelige for fremtidig lagring af data). Denne tilgang muligg\u00f8r hurtigt at tilf\u00f8je og fjerne noder uden alvorlige konsekvenser for det allerede fungerende system. Det vil sige, at systemet er meget let at skalere<\/p>\n

<\/p>\n

ved at tilf\u00f8je eller fjerne noder i klyngen efter behov. P\u00e5 puljen af ARDFS tilf\u00f8jes virtuelle diske (lagringsobjekter til virtuelle maskiner), som bygges af virtuelle blokke p\u00e5 4 megabyte. P\u00e5 de virtuelle diske opbevares dataene direkte. P\u00e5 niveauet for de virtuelle diske defineres ogs\u00e5 skemaet for fejltolerance. <\/p>\n

<\/p>\n

Som du m\u00e5ske allerede har g\u00e6ttet, bruger vi ikke RAID (Redundant array of independent Disks) konceptet til fejltolerance af disk-systemet, men i stedet RAIN (Redundant array of independent Nodes). Det vil sige, at fejltolerance m\u00e5les, automatiseres og styres baseret p\u00e5 noder frem for diske. Diskene er selvf\u00f8lgelig ogs\u00e5 lagerobjekter, de overv\u00e5ges ligesom alt andet, og man kan udf\u00f8re alle standardoperationer med dem, herunder at samle lokal hardware RAID, men clusteret opererer netop med noder. <\/p>\n

<\/p>\n

I situationer, hvor man virkelig \u00f8nsker RAID (for eksempel et scenarie, der underst\u00f8tter multiple fejlsituationer p\u00e5 sm\u00e5 clusters), er der intet, der forhindrer brugen af lokale RAID-kontrollere, og oven p\u00e5 dette at skabe et distribueret lager og RAIN-arkitektur. Et s\u00e5dant scenarie er helt realistisk og underst\u00f8ttes af os, derfor vil vi omtale det i artiklen om typiske anvendelsesscenarier for vAIR.<\/p>\n

<\/p>\n

Fejltolerance-skematikker for lager<\/h3>\n

<\/p>\n

Der kan v\u00e6re to typer fejltolerance for virtuelle diske i vAIR:<\/p>\n

<\/p>\n

1) Replikationsfaktor eller blot replikation \u2013 denne metode til fejltolerance er simpel \u00absom en stok og et reb\u00bb. Der udf\u00f8res synkron replikation mellem noderne med en faktor p\u00e5 2 (2 kopier pr. cluster) eller 3 (3 kopier, hhv.). RF-2 tillader, at den virtuelle disk kan klare fejlen af \u00e9n node i clusteren, men \u00abspiser\u00bb halvdelen af den nyttige kapacitet, mens RF-3 kan klare fejlen af 2 noder i clusteren, men reserverer allerede 2\/3 af den nyttige kapacitet til sine behov. Denne skema minder meget om RAID-1, det vil sige, at en virtuel disk konfigureret i RF-2 er modstandsdygtig over for fejlen af en hvilken som helst node i clusteren. I dette tilf\u00e6lde vil dataene v\u00e6re sikre, og selv I\/O vil ikke stoppe. N\u00e5r den faldne node vender tilbage i drift, vil automatisk gendannelse\/synkronisering af data begynde. <\/p>\n

<\/p>\n

Nedenfor er eksempler p\u00e5 distribution af data RF-2 og RF-3 i normal drift og i tilf\u00e6lde af fejl.<\/p>\n

<\/p>\n

Vi har en virtuel maskine med 8 MB unikke (nyttige) data, som k\u00f8rer p\u00e5 4 noder vAIR. Det er klart, at der i virkeligheden n\u00e6ppe vil v\u00e6re et s\u00e5 lille volumen, men til en skema, der afspejler logikken i ARDFS, er dette eksempel det mest forst\u00e5elige. AB er virtuelle blokke p\u00e5 4 MB, der indeholder unikke data fra den virtuelle maskine. Ved RF-2 oprettes der to kopier af disse blokke A1+A2 og B1+B2 henholdsvis. Disse blokke<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

fordeles <\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

p\u00e5 noderne uden at krydse de samme data p\u00e5 en enkelt node, s\u00e5 kopien A1 ikke vil v\u00e6re p\u00e5 samme node som kopien A2. B1 og B2 fungerer p\u00e5 samme m\u00e5de.<\/p>\n

<\/p>\n

N\u00e5r en af noderne fejler (for eksempel node nr. 3, hvor kopien B1 findes), aktiveres denne kopie automatisk p\u00e5 den node, hvor der ikke findes en kopi af dens kopi (dvs. kopi B2).<\/p>\n

<\/p>\n

P\u00e5 denne m\u00e5de kan den virtuelle disk (og VM'en) nemt overleve en nodes fejl i RF-2 schemaet. <\/p>\n

<\/p>\n

Schem nettet med replikation, mens det er simpelt og p\u00e5lideligt, lider under den samme svaghed som RAID1 - lidt nyttig plads. <\/p>\n

<\/p>\n

Erasure coding eller sletning af kodning (ogs\u00e5 kendt som 'overskydende kodning', 'sletningskodning' eller 'overskudskode') eksisterer netop for at l\u00f8se det ovenn\u00e6vnte problem. EC er et overskudsschema, der sikrer h\u00f8j tilg\u00e6ngelighed af data med lavere omkostninger til diskplads sammenlignet med replikation. Funktionsprincippet for denne mekanisme ligner RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Ved kodning opdele processen EC den virtuelle blok (som standard 4 MB) i flere mindre 'data stykker' afh\u00e6ngigt af EC-skemet (for eksempel deler skemaet 2+1 hver 4 MB blok i 2 stykker p\u00e5 2 MB). Derefter genererer denne proces 'paritets stykker' p\u00e5 ikke mere end \u00e9n af de tidligere opdelte dele til 'data stykkerne'. Ved dekodning genererer EC de manglende stykker ved at l\u00e6se de 'overlevende' data i hele klyngen. <\/p>\n

<\/p>\n

I sidste ende distribueres data og paritet j\u00e6vnt p\u00e5 alle noder i klyngen. Som ved replikation distribuerer ARDFS automatisk dataene p\u00e5 noderne, s\u00e5 der ikke opbevares ens data (kopier af data og deres paritet) p\u00e5 \u00e9n node, for at undg\u00e5 at miste data, hvis dataene og deres paritet pludselig skulle v\u00e6re p\u00e5 \u00e9n lagringsnode, der fejler. <\/p>\n

<\/p>\n

Nedenfor er et eksempel med den samme virtuelle maskine p\u00e5 8 MB og 4 noder, men allerede med skemaet EC 2+1. <\/p>\n

<\/p>\n

Blok A og B opdeles i to stykker, hver p\u00e5 2 MB (i to, fordi 2+1), det vil sige A1+A2 og B1+B2. I mods\u00e6tning til replikaen er A1 ikke en kopi af A2; det er en virtuel blok A, delt i to dele, det samme g\u00e6lder for blok B. I alt f\u00e5r vi to s\u00e6t p\u00e5 4 MB, hvor hvert s\u00e6t indeholder to to-megabytters stykker. Dern\u00e6st beregnes paritetsdata for hvert af disse s\u00e6t med en st\u00f8rrelse p\u00e5 h\u00f8jst et stykke (dvs. 2 MB), s\u00e5 vi f\u00e5r yderligere + 2 stykker paritet (A-P og B-P). I alt har vi 4\u00d72 data + 2\u00d72 paritet.<\/p>\n

<\/p>\n

Derefter \"fordeles\" stykkerne p\u00e5 noderne, s\u00e5 dataene ikke overlapper med deres paritet. Dvs. A1 og A2 vil ikke v\u00e6re p\u00e5 den samme node som A-P.<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

I tilf\u00e6lde af fejl p\u00e5 \u00e9n node (lad os sige den tredje) vil den fejlede blok B1 automatisk blive gendannet fra pariteten B-P, som opbevares p\u00e5 node nr. 2, og aktiveres p\u00e5 node, hvor der ikke er B-paritet, dvs. stykket B-P. I dette eksempel er det node nr. 1.<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

Jeg er sikker p\u00e5, at l\u00e6seren stiller sp\u00f8rgsm\u00e5let:<\/p>\n

<\/p>\n

\"Alt det, du har beskrevet, er allerede implementeret af konkurrenter og i open source-l\u00f8sninger, hvad er forskellen p\u00e5 jeres implementering af EC i ARDFS?\"<\/p><\/blockquote>\n

Og videre vil de interessante funktioner i ARDFS blive pr\u00e6senteret.<\/p>\n

<\/p>\n

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

<\/p>\n

Oprindeligt havde vi en ret fleksibel EC-scheme X+Y, hvor X er et tal fra 2 til 8, og Y er et tal fra 1 til 8, men altid mindre end eller lig med X. Denne ordning er designet til fleksibilitet. En stigning i antallet af datastykker (X), som den virtuelle blok opdeles i, reducerer omkostningerne, hvilket \u00f8ger det nyttige rum.
\nEn stigning i antallet af paritetsstykker (Y) \u00f8ger p\u00e5lideligheden af den virtuelle disk. Jo h\u00f8jere Y-v\u00e6rdien er, desto flere noder i klyngen kan fejle. Selvf\u00f8lgelig reducerer en stigning i volumen af paritet det nyttige kapacitet, men det er prisen for p\u00e5lidelighed. <\/p>\n

<\/p>\n

Afh\u00e6ngigheden af ydeevne fra EC-skemaer er n\u00e6sten direkte: jo flere \"klumper\", desto lavere ydeevne, her er der behov for et afbalanceret syn. <\/p>\n

<\/p>\n

Denne tilgang g\u00f8r det muligt for administratorer at konfigurere et distribueret lager s\u00e5 fleksibelt som muligt. Inden for ARDFS-puljen kan man anvende enhver form for fejltolerance og deres kombinationer, hvilket ogs\u00e5 er meget nyttigt, efter vores mening. <\/p>\n

<\/p>\n

Nedenfor er en sammenligningstabel af flere (ikke alle mulige) RF- og EC-skemaer.<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

Det fremg\u00e5r af tabellen, at selv den mest \"udviklede\" EC-kombination 8+7, der tillader tab af op til 7 noder i klyngen samtidigt, \"spiser\" mindre nyttig plads (1,875 mod 2) end standard replikation, mens den beskytter 7 gange bedre, hvilket g\u00f8r denne beskyttelsesmekanisme mere kompleks men betydeligt mere attraktiv i situationer, hvor maksimal p\u00e5lidelighed kr\u00e6ves under omst\u00e6ndigheder med begr\u00e6nset diskplads. Det skal dog forst\u00e5s, at hver \"plus\" til X eller Y vil medf\u00f8re yderligere omkostninger for ydeevnen, derfor skal der v\u00e6lges meget omhyggeligt i trekanter mellem p\u00e5lidelighed, besparelse og ydeevne. Af denne grund vil vi dedikere en separat artikel til sizing af codering.<\/p>\n

<\/p>\n

\"Hyperkonvergerende<\/p>\n

<\/p>\n

P\u00e5lidelighed og autonomi i filsystemet<\/h3>\n

<\/p>\n

ARDFS k\u00f8rer lokalt p\u00e5 alle noder i klyngen og synkroniserer dem ved hj\u00e6lp af dedikerede Ethernet-gr\u00e6nseflader. Et vigtigt punkt er, at ARDFS selv synkroniserer ikke kun data men ogs\u00e5 metadata relateret til opbevaring. Under arbejdet med ARDFS har vi samtidig unders\u00f8gt en r\u00e6kke eksisterende l\u00f8sninger, og vi har fundet ud af, at mange bruger en ekstern distribueret DBMS til synkronisering af metadata i filsystemet, hvilket vi ogs\u00e5 bruger til synkronisering af konfigurationer, men ikke metadata fra FS (om dette og andre besl\u00e6gtede systemer i den n\u00e6ste artikel). <\/p>\n

<\/p>\n

Samarbejdningen om metadata-synkronisering med en ekstern DBMS er selvf\u00f8lgelig en funktionel l\u00f8sning, men s\u00e5 ville datakonsistensen lagret p\u00e5 ARDFS v\u00e6re afh\u00e6ngig af den eksterne DBMS og dens opf\u00f8rsel (som vi m\u00e5 sige er ret lunefuld), hvilket vi anser for problematisk. Hvorfor? Hvis metadataene i FS beskadiges, vil selv dataene i FS ogs\u00e5 v\u00e6re sagt \u00abfarvel\u00bb, s\u00e5 vi besluttede at tage en mere kompleks, men p\u00e5lidelig vej. <\/p>\n

<\/p>\n

Vi har selv lavet subsystemet til metadata-synkronisering til ARDFS, og det fungerer helt uafh\u00e6ngigt af nabosystemer. Dvs. ingen andre subsystemer kan beskadige dataene i ARDFS. Efter vores mening er dette den mest p\u00e5lidelige og korrekte vej, og om det virkelig er s\u00e5dan, vil tiden vise. Desuden giver denne tilgang en ekstra fordel. ARDFS kan bruges uafh\u00e6ngigt af vAIR, blot som en udvidet lagerl\u00f8sning, hvilket vi bestemt vil udnytte i fremtidige produkter.<\/p>\n

<\/p>\n

Som resultat af udviklingen af ARDFS har vi f\u00e5et et fleksibelt og p\u00e5lideligt filsystem, der giver valgmuligheder for, hvor man kan spare p\u00e5 kapaciteten eller s\u00e6tte alt ind p\u00e5 ydeevnen, eller g\u00f8re lageret ekstremt p\u00e5lideligt for en moderat pris, men med reducerede ydeevnekrav. <\/p>\n

<\/p>\n

Sammen med en enkel licenspolitik og en fleksibel leveringsmodel (for at forudse, licenseres vAIR pr. node, og leveres enten som software eller som PAK) g\u00f8r det muligt meget pr\u00e6cist at tilpasse l\u00f8sningen til forskellige kundekrav og nemt vedligeholde denne balance i fremtiden. <\/p>\n

<\/p>\n

Hvem har brug for dette vidunder?<\/h2>\n

<\/p>\n

P\u00e5 den ene side kan man sige, at der allerede er spillere p\u00e5 markedet med seri\u00f8se l\u00f8sninger inden for hyperkonvergens, og at vi egentlig ikke burde blande os. Det virker som en korrekt p\u00e5stand, MEN...<\/p>\n

<\/p>\n

P\u00e5 den anden side, n\u00e5r vi kommer \u00abud i marken\u00bb og taler med kunder, ser vi, at det helt bestemt ikke er s\u00e5dan. Der er mange opgaver for hyperkonvergens, nogle mennesker vidste bare ikke, at s\u00e5danne l\u00f8sninger eksisterede, i nogle tilf\u00e6lde virkede det for dyrt, i andre var der mislykkede tests af alternative l\u00f8sninger, og i andre er k\u00f8b endda forbudt p\u00e5 grund af sanktioner. Generelt viste marken sig at v\u00e6re upl\u00f8jet, og derfor gik vi i gang med at tage fat p\u00e5 det.) <\/p>\n

<\/p>\n

Hvorn\u00e5r er SCS bedre end GCS?<\/h3>\n

<\/p>\n

I takt med vores arbejde p\u00e5 markedet f\u00e5r vi ofte sp\u00f8rgsm\u00e5let om, hvorn\u00e5r man bedst anvender den klassiske model med SAN, og hvorn\u00e5r man skal bruge hyperkonvergerede l\u00f8sninger? Mange virksomheder, der producerer HCI (is\u00e6r dem uden SAN i deres portef\u00f8lje), siger: \"SAN er ved at d\u00f8 ud, hyperkonvergeret er vejen frem!\". Dette er en dristig p\u00e5stand, men den afspejler ikke helt virkeligheden. <\/p>\n

<\/p>\n

For at v\u00e6re \u00e6rlig bev\u00e6ger SAN-markedet sig virkelig mod hyperkonvergerede l\u00f8sninger, men der er altid et 'men'.<\/p>\n

<\/p>\n

For det f\u00f8rste er det ikke s\u00e5 let at ombygge eksisterende datacentre og IT-infrastrukturer, der er bygget med den klassiske model med SAN, s\u00e5 opgradering og udvidelse af s\u00e5danne infrastrukturer er stadig en arv i 5-7 \u00e5r.<\/p>\n

<\/p>\n

For det andet bygger de infrastrukturer, der i \u00f8jeblikket etableres i massevis (her menes Rusland), overvejende efter den klassiske model med brug af SAN, ikke fordi folk ikke kender til hyperkonvergerede l\u00f8sninger, men fordi markedet for hyperkonvergerede l\u00f8sninger er nyt, l\u00f8sninger og standarder er endnu ikke etableret, IT-specialisterne er ikke tilstr\u00e6kkeligt uddannede, erfaringen er lille, og datacentre skal bygges her og nu. Denne tendens vil vare i yderligere 3-5 \u00e5r (og s\u00e5 er der stadig arv, jf. punkt 1).<\/p>\n

<\/p>\n

For det tredje er der en rent teknisk begr\u00e6nsning i de ekstra sm\u00e5 forsinkelser p\u00e5 2 millisekunder ved skrivning (uden hensyntagen til lokal cache, selvf\u00f8lgelig), som er prisen for distribueret lagring. <\/p>\n

<\/p>\n

Og lad os ikke glemme brugen af store fysiske servere, som elsker vertikal scaling af disk-undersystemet.<\/p>\n

<\/p>\n

Der er mange n\u00f8dvendige og popul\u00e6re opgaver, hvor SAN pr\u00e6sterer bedre end HCI. Selvf\u00f8lgelig vil producenter uden SAN i deres produktportef\u00f8lje ikke v\u00e6re enige i dette, men vi er klar til at argue vores sag. Som udviklere af begge produkter vil vi i en af de kommende publikationer bestemt sammenligne SAN og HCI, hvor vi tydeligt vil demonstrere, hvorn\u00e5r hvilke forhold er bedst.<\/p>\n

<\/p>\n

Og hvor vil hyperkonvergerede l\u00f8sninger fungere bedre end SAN?<\/h3>\n

<\/p>\n

Baseret p\u00e5 de tidligere n\u00e6vnte punkter kan der drages tre \u00e5benlyse konklusioner: <\/p>\n

<\/p>\n

    \n
  1. Der, hvor de ekstra 2 millisekunders forsinkelse ved skrivning, som regelm\u00e6ssigt opst\u00e5r i al produktionsmilj\u00f8 (denne diskussion omhandler ikke syntetisk tester, da disse kan vise nanosekunders forskelle), ikke er kritiske, er hyperkonvergerede l\u00f8sninger velegnede.<\/li>\n
  2. Der, hvor belastningen fra store fysiske servere kan omdannes til mange sm\u00e5 virtuelle og distribueres over noder, vil hyperkonvergerede l\u00f8sninger ogs\u00e5 finde godt fodf\u00e6ste.<\/li>\n
  3. Der, hvor horisontal skalering er mere prioriteret end vertikal, vil hyperkonvergerede systemer ogs\u00e5 fungere fremragende.<\/li>\n<\/ol>\n

    <\/p>\n

    Hvilke l\u00f8sninger er der?<\/h3>\n

    <\/p>\n

      \n
    1. Alle standardinfrastrukturtjenester (katalogtjeneste, e-mail, DMS, filservere, sm\u00e5 eller mellemstore ERP- og BI-systemer osv.). Vi kalder det \"f\u00e6lles beregninger\". <\/li>\n
    2. Infrastrukturen hos cloududbydere, hvor det er n\u00f8dvendigt at skaler hurtigt og standardiseret horisontalt og nemt \"sk\u00e6re\" mange virtuelle maskiner til kunder.<\/li>\n
    3. Infrastruktur for virtuelle skriveborde<\/a> (VDI), hvor mange sm\u00e5 bruger-virtualer starter op og frit \"sv\u00f8mmer\" inden for et enhedligt cluster.<\/li>\n
    4. Filialnetv\u00e6rk, hvor hver filial har brug for en standard, fejltolerance, men samtidig prisvenlig infrastruktur best\u00e5ende af 15-20 virtuelle maskiner.<\/li>\n
    5. Enhver distribueret beregning (big data-tjenester, for eksempel). Der, hvor belastningen g\u00e5r ikke \"nedad\", men \"udad\". <\/li>\n
    6. Testmilj\u00f8er, hvor der kan v\u00e6re sm\u00e5 yderligere forsinkelser, men der er budgetm\u00e6ssige begr\u00e6nsninger, da det er tests.<\/li>\n<\/ol>\n

      <\/p>\n

      I \u00f8jeblikket har vi udviklet AERODISK vAIR specifikt til disse opgaver, og vi fokuserer netop p\u00e5 dem (indtil videre med succes). Det er muligt, at dette snart vil \u00e6ndre sig, da verden ikke st\u00e5r stille.<\/p>\n

      <\/p>\n

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

      <\/p>\n

      Med dette er den f\u00f8rste del af en stor cyklus af artikler afsluttet; i den n\u00e6ste artikel vil vi fort\u00e6lle om arkitekturen af l\u00f8sningen og de anvendte komponenter.<\/p>\n

      <\/p>\n

      Vi ser frem til sp\u00f8rgsm\u00e5l, forslag og konstruktive diskussioner.<\/p>\n

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