Hej Habr læsere. Med denne artikel åbner vi en serie, der vil tale om det hyperkonvergerede system AERODISK vAIR, som vi har udviklet. I første omgang ville vi fortælle alt om alt i den første artikel, men systemet er ret komplekst, så vi spiser elefanten i dele.
Lad os starte historien med historien om oprettelsen af systemet, dykke ned i ARDFS-filsystemet, som er grundlaget for vAIR, og også tale lidt om placeringen af denne løsning på det russiske marked.
I fremtidige artikler vil vi tale mere detaljeret om forskellige arkitektoniske komponenter (klynge, hypervisor, belastningsbalancer, overvågningssystem osv.), konfigurationsprocessen, rejse licensproblemer, separat vise crashtest og selvfølgelig skrive om belastningstest og dimensionering. Vi vil også afsætte en separat artikel til fællesskabsversionen af vAIR.
Er Aerodisk en historie om lagersystemer? Eller hvorfor begyndte vi at lave hyperkonvergens i første omgang?
Oprindeligt kom ideen til at skabe vores egen hyperkonvergens til os et sted omkring 2010. På det tidspunkt var der hverken Aerodisk eller lignende løsninger (kommercielle boxed hyperconverged systems) på markedet. Vores opgave var følgende: Fra et sæt servere med lokale diske, forenet af en sammenkobling via Ethernet-protokollen, var det nødvendigt at oprette et udvidet lager og starte virtuelle maskiner og et softwarenetværk der. Alt dette skulle implementeres uden lagersystemer (fordi der simpelthen ikke var penge til lagersystemer og dets hardware, og vi havde endnu ikke opfundet vores egne lagersystemer).
Vi prøvede mange open source-løsninger og løste til sidst dette problem, men løsningen var meget kompleks og svær at gentage. Desuden var denne løsning i kategorien "Virker det? Rør ikke! Derfor, efter at have løst det problem, videreudviklede vi ikke ideen om at transformere resultatet af vores arbejde til et fuldgyldigt produkt.
Efter den hændelse gik vi væk fra denne idé, men vi havde stadig følelsen af, at dette problem var fuldstændigt løseligt, og fordelene ved en sådan løsning var mere end indlysende. Efterfølgende bekræftede de frigivne HCI-produkter fra udenlandske virksomheder kun denne følelse.
Derfor vendte vi midt i 2016 tilbage til denne opgave som led i at skabe et fuldgyldigt produkt. På det tidspunkt havde vi endnu ingen relationer til investorer, så vi måtte købe en udviklingsstand for vores egne ikke ret store penge. Efter at have samlet brugte servere og switche på Avito, gik vi i gang.
Den primære indledende opgave var at skabe vores eget, omend simple, men vores eget filsystem, som automatisk og jævnt kunne fordele data i form af virtuelle blokke på det n. antal klynge noder, som er forbundet med en sammenkobling via Ethernet. Samtidig skal FS'en skalere godt og let og være uafhængig af tilstødende systemer, dvs. være fremmedgjort fra vAIR i form af "bare en lagerfacilitet".
Første vAIR koncept
Vi har bevidst opgivet brugen af færdige open source-løsninger til organisering af stretched storage (ceph, gluster, luster og lignende) til fordel for vores egen udvikling, da vi allerede havde en del projekterfaring med dem. Selvfølgelig er disse løsninger i sig selv fremragende, og før vi arbejdede på Aerodisk, implementerede vi mere end ét integrationsprojekt med dem. Men én ting er at implementere en specifik opgave for én kunde, uddanne personale og måske købe support fra en stor leverandør, og en helt anden ting at skabe et let replikeret produkt, der skal bruges til forskellige opgaver, som vi som sælger, måske endda vide om os selv, vi vil ikke. Til det andet formål var eksisterende open source-produkter ikke egnede til os, så vi besluttede at lave et distribueret filsystem selv.
To år senere opnåede flere udviklere (som kombinerede arbejdet med vAIR med arbejdet med det klassiske Engine-lagringssystem) et bestemt resultat.
I 2018 havde vi skrevet et simpelt filsystem og suppleret det med den nødvendige hardware. Systemet kombinerede fysiske (lokale) diske fra forskellige servere til én flad pool via en intern sammenkobling og "skar" dem i virtuelle blokke, hvorefter der blev oprettet blokenheder med varierende grader af fejltolerance fra de virtuelle blokke, hvorpå der blev oprettet virtuelle blokke. og udført ved hjælp af KVM hypervisor-biler.
Vi bekymrede os ikke for meget om navnet på filsystemet og kaldte det kort og godt ARDFS (gæt hvad det står for))
Denne prototype så godt ud (ikke visuelt, selvfølgelig, der var ikke noget visuelt design endnu) og viste gode resultater med hensyn til ydeevne og skalering. Efter det første rigtige resultat satte vi dette projekt i gang, og organiserede et fuldgyldigt udviklingsmiljø og et separat team, der kun beskæftigede sig med vAIR.
Netop på det tidspunkt var løsningens generelle arkitektur modnet, som endnu ikke har gennemgået større ændringer.
Dykker ned i ARDFS-filsystemet
ARDFS er grundlaget for vAIR, som giver distribueret, fejltolerant datalagring på tværs af hele klyngen. Et af (men ikke det eneste) karakteristiske træk ved ARDFS er, at det ikke bruger nogen ekstra dedikerede servere til metadata og administration. Dette blev oprindeligt udtænkt for at forenkle konfigurationen af løsningen og for dens pålidelighed.
Opbevaringsstruktur
Inden for alle noder i klyngen organiserer ARDFS en logisk pulje fra al tilgængelig diskplads. Det er vigtigt at forstå, at en pulje endnu ikke er data eller formateret rum, men blot markup, dvs. Alle noder med vAIR installeret, når de føjes til klyngen, føjes automatisk til den delte ARDFS-pulje, og diskressourcer bliver automatisk delt på tværs af hele klyngen (og tilgængelige for fremtidig datalagring). Denne tilgang giver dig mulighed for at tilføje og fjerne noder i farten uden nogen alvorlig indvirkning på det allerede kørende system. De der. systemet er meget nemt at skalere "i klodser", tilføje eller fjerne noder i klyngen om nødvendigt.
Virtuelle diske (lagringsobjekter til virtuelle maskiner) tilføjes oven på ARDFS-puljen, som er bygget af virtuelle blokke på 4 megabyte i størrelse. Virtuelle diske gemmer direkte data. Fejltoleranceskemaet er også indstillet på det virtuelle diskniveau.
Som du måske allerede har gættet, bruger vi ikke konceptet RAID (Redundant array of independent Disks), af hensyn til fejltolerance for diskundersystemet, men RAIN (Redundant array of independent Nodes). De der. Fejltolerance måles, automatiseres og styres baseret på noderne, ikke diskene. Diske er selvfølgelig også et lagringsobjekt, de overvåges ligesom alt andet, du kan udføre alle standardoperationer med dem, inklusive samling af et lokalt hardware-RAID, men klyngen fungerer specifikt på noder.
I en situation, hvor du virkelig ønsker RAID (for eksempel et scenarie, der understøtter flere fejl på små klynger), forhindrer intet dig i at bruge lokale RAID-controllere og bygge strakt lager og en RAIN-arkitektur ovenpå. Dette scenarie er ganske live og understøttes af os, så vi vil tale om det i en artikel om typiske scenarier for brug af vAIR.
Opbevaringsfejltoleranceskemaer
Der kan være to fejltoleranceskemaer for virtuelle diske i vAIR:
1) Replikationsfaktor eller blot replikation - denne fejltolerancemetode er så simpel som en pind og et reb. Synkron replikering udføres mellem noder med en faktor på henholdsvis 2 (2 kopier pr. klynge) eller 3 (3 kopier). RF-2 gør det muligt for en virtuel disk at modstå svigt af en node i klyngen, men "spiser" halvdelen af den nyttige volumen, og RF-3 vil modstå svigt af 2 noder i klyngen, men reserverer 2/3 af nyttig volumen til dets behov. Dette skema ligner meget RAID-1, det vil sige, at en virtuel disk, der er konfigureret i RF-2, er modstandsdygtig over for svigt af en hvilken som helst node i klyngen. I dette tilfælde vil alt være fint med dataene, og selv I/O vil ikke stoppe. Når den faldne node vender tilbage til tjeneste, begynder automatisk datagendannelse/synkronisering.
Nedenfor er eksempler på distribution af RF-2 og RF-3 data i normal tilstand og i en fejlsituation.
Vi har en virtuel maskine med en kapacitet på 8MB unikke (nyttige) data, som kører på 4 vAIR noder. Det er klart, at det i virkeligheden er usandsynligt, at der vil være så lille et volumen, men for en ordning, der afspejler logikken i ARDFS-driften, er dette eksempel det mest forståelige. AB er 4MB virtuelle blokke, der indeholder unikke virtuelle maskindata. RF-2 opretter to kopier af disse blokke henholdsvis A1+A2 og B1+B2. Disse blokke er "lagt ud" på tværs af noder, og undgår skæringspunktet mellem de samme data på den samme node, dvs. kopi A1 vil ikke være placeret på samme node som kopi A2. Det samme med B1 og B2.
Hvis en af noderne fejler (f.eks. node nr. 3, som indeholder en kopi af B1), aktiveres denne kopi automatisk på noden, hvor der ikke er nogen kopi af dens kopi (det vil sige en kopi af B2).
Således kan den virtuelle disk (og VM'en i overensstemmelse hermed) nemt overleve fejlen i en knude i RF-2-skemaet.
Selv om replikeringsskemaet er enkelt og pålideligt, lider det af det samme problem som RAID1 - ikke nok brugbar plads.
2) Slettekodning eller slettekodning (også kendt som "redundant kodning", "slettekodning" eller "redundanskode") findes for at løse problemet ovenfor. EC er et redundansskema, der giver høj datatilgængelighed med lavere diskpladsoverhead sammenlignet med replikering. Funktionsprincippet for denne mekanisme ligner RAID 5, 6, 6P.
Ved kodning opdeler EC-processen en virtuel blok (4MB som standard) i flere mindre "databidder" afhængigt af EC-skemaet (for eksempel opdeler et 2+1-skema hver 4MB-blok i 2 2MB-bidder). Dernæst genererer denne proces "paritetsstykker" for "datastykkerne", der ikke er større end en af de tidligere opdelte dele. Ved afkodning genererer EC de manglende bidder ved at læse de "overlevende" data på tværs af hele klyngen.
For eksempel vil en virtuel disk med et 2 + 1 EC-skema, implementeret på 4 klynge noder, let modstå svigt af en node i klyngen på samme måde som RF-2. I dette tilfælde vil overheadomkostningerne være lavere, især den brugbare kapacitetskoefficient for RF-2 er 2, og for EC 2+1 vil den være 1,5.
For at beskrive det mere enkelt er essensen, at den virtuelle blok er opdelt i 2-8 (hvorfor fra 2 til 8, se nedenfor) "stykker", og for disse stykker beregnes "stykker" af paritet af et lignende volumen.
Som et resultat er data og paritet jævnt fordelt på tværs af alle noder i klyngen. På samme tid, som med replikering, distribuerer ARDFS automatisk data mellem noder på en sådan måde, at identiske data (kopier af data og deres paritet) forhindres i at blive lagret på den samme node, for at eliminere risikoen for at miste data pga. til, at dataene og deres paritet pludselig vil ende på én lagerknude, der fejler.
Nedenfor er et eksempel med den samme virtuelle maskine på 8 MB og 4 noder, men med et EC 2+1-skema.
Blok A og B er opdelt i to stykker på 2 MB hver (to fordi 2+1), det vil sige A1+A2 og B1+B2. I modsætning til en replika er A1 ikke en kopi af A2, det er en virtuel blok A, opdelt i to dele, det samme med blok B. I alt får vi to sæt på 4MB, som hver indeholder to to-MB-stykker. Dernæst beregnes paritet for hvert af disse sæt med et volumen på ikke mere end et stykke (dvs. 2 MB), vi opnår yderligere + 2 stykker paritet (AP og BP). I alt har vi 4×2 data + 2×2 paritet.
Dernæst bliver brikkerne "lagt ud" blandt noderne, så dataene ikke krydser deres paritet. De der. A1 og A2 vil ikke være på samme node som AP.
I tilfælde af fejl på en knude (f.eks. også den tredje), vil den faldne blok B1 automatisk blive gendannet fra BP-pariteten, som er lagret på knude nr. 2, og aktiveres på den knude, hvor der er ingen B-paritet, dvs. stykke BP. I dette eksempel er dette node nr. 1
Jeg er sikker på, at læseren har et spørgsmål:
"Alt, hvad du beskrev, har længe været implementeret både af konkurrenter og i open source-løsninger, hvad er forskellen på din implementering af EC i ARDFS?"
Og så vil der være interessante funktioner i ARDFS.
Sletning af kodning med fokus på fleksibilitet
Til at begynde med leverede vi et ret fleksibelt EC X+Y-skema, hvor X er lig med et tal fra 2 til 8, og Y er lig med et tal fra 1 til 8, men altid mindre end eller lig med X. Dette skema er angivet for fleksibilitet. Forøgelse af antallet af datastykker (X), som den virtuelle blok er opdelt i, gør det muligt at reducere overheadomkostninger, det vil sige at øge brugbar plads.
Forøgelse af antallet af paritetsstykker (Y) øger pålideligheden af den virtuelle disk. Jo større Y-værdi, jo flere noder i klyngen kan fejle. Naturligvis reducerer en forøgelse af paritetsvolumen mængden af brugbar kapacitet, men dette er en pris at betale for pålidelighed.
Ydeevnens afhængighed af EC-kredsløb er næsten direkte: Jo flere "stykker", jo lavere ydeevne; her er der selvfølgelig brug for et afbalanceret syn.
Denne tilgang giver administratorer mulighed for at konfigurere strakt opbevaring med maksimal fleksibilitet. Inden for ARDFS-puljen kan du bruge alle fejltoleranceskemaer og deres kombinationer, hvilket efter vores mening også er meget nyttigt.
Nedenfor er en tabel, der sammenligner flere (ikke alle mulige) RF- og EC-skemaer.
Tabellen viser, at selv den mest "frotté" kombination EC 8+7, som tillader tab af op til 7 noder i en klynge samtidigt, "spiser" mindre brugbar plads (1,875 versus 2) end standard replikering og beskytter 7 gange bedre , hvilket gør denne beskyttelsesmekanisme, selv om den er mere kompleks, meget mere attraktiv i situationer, hvor det er nødvendigt at sikre maksimal pålidelighed under forhold med begrænset diskplads. Samtidig skal du forstå, at hvert "plus" til X eller Y vil være en ekstra ydeevne overhead, så i trekanten mellem pålidelighed, besparelser og ydeevne skal du vælge meget omhyggeligt. Af denne grund vil vi afsætte en separat artikel til sletning af kodningsstørrelser.
Pålidelighed og autonomi af filsystemet
ARDFS kører lokalt på alle noder i klyngen og synkroniserer dem ved hjælp af sine egne midler gennem dedikerede Ethernet-grænseflader. Det vigtige er, at ARDFS uafhængigt synkroniserer ikke kun dataene, men også metadataene relateret til lagring. Mens vi arbejdede på ARDFS, studerede vi samtidig en række eksisterende løsninger, og vi opdagede, at mange synkroniserer filsystemets meta ved hjælp af et eksternt distribueret DBMS, som vi også bruger til synkronisering, men kun konfigurationer, ikke FS-metadata (om dette og andre relaterede undersystemer). i næste artikel).
Synkronisering af FS-metadata ved hjælp af et eksternt DBMS er selvfølgelig en fungerende løsning, men så ville konsistensen af de data, der er gemt på ARDFS afhænge af den eksterne DBMS og dens adfærd (og ærligt talt er det en lunefuld dame), som i vores mening er dårlig. Hvorfor? Hvis FS-metadataene bliver beskadiget, kan selve FS-dataene også siges "farvel", så vi besluttede at tage en mere kompleks, men pålidelig vej.
Vi har selv lavet metadatasynkroniseringsundersystemet til ARDFS, og det lever fuldstændig uafhængigt af tilstødende undersystemer. De der. intet andet undersystem kan ødelægge ARDFS-data. Efter vores mening er dette den mest pålidelige og korrekte måde, men tiden vil vise, om det faktisk er tilfældet. Derudover er der en yderligere fordel ved denne fremgangsmåde. ARDFS kan bruges uafhængigt af vAIR, ligesom strakt opbevaring, som vi helt sikkert vil bruge i fremtidige produkter.
Som et resultat, ved at udvikle ARDFS, modtog vi et fleksibelt og pålideligt filsystem, der giver et valg, hvor du kan spare på kapaciteten eller give afkald på ydeevnen, eller lave ultra-pålidelig lagring til en rimelig pris, men reducerer ydeevnekravene.
Sammen med en enkel licenspolitik og en fleksibel leveringsmodel (fremadrettet er vAIR licenseret af node, og leveret enten som software eller som en softwarepakke), giver dette dig mulighed for meget præcist at skræddersy løsningen til en bred vifte af kundekrav og så kan du nemt bevare denne balance.
Hvem har brug for dette mirakel?
På den ene side kan vi sige, at der allerede er aktører på markedet, som har seriøse løsninger inden for hyperkonvergens, og det er her, vi faktisk er på vej hen. Det ser ud til, at dette udsagn er sandt, MEN...
Når vi derimod går ud i markerne og kommunikerer med kunderne, ser vi og vores samarbejdspartnere, at det slet ikke er tilfældet. Der er mange opgaver for hyperkonvergens, nogle steder vidste folk simpelthen ikke, at sådanne løsninger fandtes, andre virkede det dyre, andre var der mislykkede tests af alternative løsninger, og andre steder forbyder de overhovedet at købe på grund af sanktioner. Generelt viste marken sig at være upløjet, så vi gik for at hæve jomfruelig jord))).
Hvornår er lagringssystem bedre end GCS?
Når vi arbejder med markedet, bliver vi ofte spurgt, hvornår det er bedre at bruge en klassisk ordning med lagersystemer, og hvornår skal man bruge hyperkonvergent? Mange virksomheder, der producerer GCS (især dem, der ikke har lagersystemer i deres portefølje) siger: "Lagersystemer er ved at blive forældede, kun hyperkonvergerede!" Dette er et modigt udsagn, men det afspejler ikke helt virkeligheden.
I sandhed bevæger lagringsmarkedet sig faktisk mod hyperkonvergens og lignende løsninger, men der er altid et "men".
For det første kan datacentre og it-infrastrukturer bygget efter den klassiske ordning med lagersystemer ikke let genopbygges, så moderniseringen og færdiggørelsen af sådanne infrastrukturer er stadig en arv i 5-7 år.
For det andet er den infrastruktur, der i øjeblikket bygges for det meste (det vil sige Den Russiske Føderation) bygget i henhold til den klassiske ordning ved hjælp af lagersystemer, og ikke fordi folk ikke kender til hyperkonvergens, men fordi hyperkonvergensmarkedet er nyt, løsninger og standarder er endnu ikke etableret, it-folk er endnu ikke uddannet, de har ringe erfaring, men de skal bygge datacentre her og nu. Og denne tendens vil vare i yderligere 3-5 år (og så endnu en arv, se punkt 1).
For det tredje er der en rent teknisk begrænsning i yderligere små forsinkelser på 2 millisekunder pr. skrivning (undtagen den lokale cache, selvfølgelig), som er omkostningerne ved distribueret lagring.
Nå, lad os ikke glemme brugen af store fysiske servere, der elsker vertikal skalering af diskundersystemet.
Der er mange nødvendige og populære opgaver, hvor lagersystemer opfører sig bedre end GCS. Her vil de producenter, der ikke har lagersystemer i deres produktportefølje, selvfølgelig ikke give os ret, men vi er klar til at argumentere rimeligt. Selvfølgelig vil vi som udviklere af begge produkter helt sikkert sammenligne lagersystemer og GCS i en af vores fremtidige publikationer, hvor vi tydeligt vil demonstrere, hvilken der er bedre under hvilke forhold.
Og hvor vil hyperkonvergerede løsninger fungere bedre end lagersystemer?
Ud fra ovenstående punkter kan der drages tre indlysende konklusioner:
- Hvor yderligere 2 millisekunders latency til optagelse, som konsekvent forekommer i ethvert produkt (nu taler vi ikke om syntetiske, nanosekunder kan vises på syntetiske stoffer), er ukritisk, er hyperkonvergent velegnet.
- Hvor belastningen fra store fysiske servere kan omdannes til mange små virtuelle og fordeles mellem noder, vil hyperkonvergens også fungere godt der.
- Hvor horisontal skalering er en højere prioritet end vertikal skalering, vil GCS også klare sig fint der.
Hvad er disse løsninger?
- Alle standard infrastrukturtjenester (katalogtjeneste, mail, EDMS, filservere, små eller mellemstore ERP- og BI-systemer osv.). Vi kalder dette "generel databehandling."
- Infrastrukturen hos cloud-udbydere, hvor det er nødvendigt hurtigt og standardiseret horisontalt at udvide og nemt "skære" et stort antal virtuelle maskiner for kunderne.
- Virtuel desktop-infrastruktur (VDI), hvor mange virtuelle små brugermaskiner kører og stille og roligt "svæver" i en ensartet klynge.
- Filialnetværk, hvor hver filial har brug for en standard, fejltolerant, men billig infrastruktur på 15-20 virtuelle maskiner.
- Enhver distribueret databehandling (f.eks. big data-tjenester). Hvor belastningen ikke går "i dybden", men "i bredden".
- Testmiljøer, hvor yderligere små forsinkelser er acceptable, men der er budgetbegrænsninger, fordi disse er tests.
I øjeblikket er det til disse opgaver, vi har lavet AERODISK vAIR, og det er på dem, vi fokuserer (med succes indtil videre). Måske ændres det snart, fordi... verden står ikke stille.
Så…
Dette afslutter første del af en stor serie af artikler; i den næste artikel vil vi tale om løsningens arkitektur og de anvendte komponenter.
Vi modtager gerne spørgsmål, forslag og konstruktive stridigheder.
Kilde: www.habr.com