Hej, Habr-läsare. Med den här artikeln öppnar vi en serie som kommer att prata om det hyperkonvergerade systemet AERODISK vAIR som vi har utvecklat. Från början ville vi berätta allt om allt i den första artikeln, men systemet är ganska komplext, så vi kommer att äta elefanten i delar.
Låt oss börja historien med historien om skapandet av systemet, fördjupa oss i ARDFS-filsystemet, som är grunden för vAIR, och också prata lite om placeringen av denna lösning på den ryska marknaden.
I framtida artiklar kommer vi att prata mer i detalj om olika arkitektoniska komponenter (kluster, hypervisor, lastbalanserare, övervakningssystem etc.), konfigurationsprocessen, ta upp licensfrågor, visa krocktester separat och, naturligtvis, skriva om lasttestning och dimensionering. Vi kommer också att ägna en separat artikel åt communityversionen av vAIR.
Är Aerodisk en berättelse om lagringssystem? Eller varför började vi göra hyperkonvergens från första början?
Från början kom idén att skapa vår egen hyperkonvergens till oss någonstans runt 2010. På den tiden fanns det varken Aerodisk eller liknande lösningar (kommersiella boxade hyperkonvergerade system) på marknaden. Vår uppgift var följande: från en uppsättning servrar med lokala diskar, förenade av en sammankoppling via Ethernet-protokollet, var det nödvändigt att skapa en utökad lagring och starta virtuella maskiner och ett mjukvarunätverk där. Allt detta måste implementeras utan lagringssystem (eftersom det helt enkelt inte fanns några pengar till lagringssystem och dess hårdvara, och vi hade ännu inte uppfunnit våra egna lagringssystem).
Vi provade många lösningar med öppen källkod och löste till slut detta problem, men lösningen var mycket komplex och svår att upprepa. Dessutom var den här lösningen i kategorin "Fungerar det? Rör inte! Därför, efter att ha löst det problemet, vidareutvecklade vi inte idén om att omvandla resultatet av vårt arbete till en fullfjädrad produkt.
Efter den incidenten gick vi bort från denna idé, men vi hade fortfarande känslan av att det här problemet var helt lösbart, och fördelarna med en sådan lösning var mer än uppenbara. Därefter bekräftade de släppta HCI-produkterna från utländska företag bara denna känsla.
Därför återgick vi i mitten av 2016 till denna uppgift som en del av att skapa en fullfjädrad produkt. Då hade vi ännu inga relationer med investerare, så vi fick köpa ett utvecklingsställ för våra egna inte särskilt stora pengar. Efter att ha samlat in begagnade servrar och switchar på Avito kom vi igång.
Den huvudsakliga initiala uppgiften var att skapa vårt eget, om än enkla, men vårt eget filsystem, som automatiskt och jämnt kunde distribuera data i form av virtuella block på det n:te antalet klusternoder, som är sammankopplade med en sammankoppling via Ethernet. Samtidigt bör FS skala bra och enkelt och vara oberoende av intilliggande system, d.v.s. vara alienerad från vAIR i form av "bara en lagringsanläggning".
Första vAIR-konceptet
Vi övergav medvetet användningen av färdiga lösningar med öppen källkod för att organisera sträckt lagring (ceph, gluster, lyster och liknande) till förmån för vår egen utveckling, eftersom vi redan hade mycket projekterfarenhet med dem. Naturligtvis är dessa lösningar i sig utmärkta, och innan vi arbetade på Aerodisk implementerade vi mer än ett integrationsprojekt med dem. Men det är en sak att implementera en specifik uppgift för en kund, utbilda personal och kanske köpa support från en stor leverantör, och en helt annan sak att skapa en lätt replikerad produkt som kommer att användas för olika uppgifter, som vi som en leverantör, kanske till och med vet om oss själva, vi kommer inte att göra det. För det andra ändamålet var befintliga open source-produkter inte lämpliga för oss, så vi bestämde oss för att skapa ett distribuerat filsystem själva.
Två år senare uppnådde flera utvecklare (som kombinerade arbetet med vAIR med arbetet med det klassiska Engine-lagringssystemet) ett visst resultat.
År 2018 hade vi skrivit ett enkelt filsystem och kompletterat det med nödvändig hårdvara. Systemet kombinerade fysiska (lokala) diskar från olika servrar till en platt pool via en intern sammankoppling och "skar ut" dem i virtuella block, sedan skapades blockenheter med olika grader av feltolerans från de virtuella blocken, på vilka virtuella skapades och exekveras med KVM-hypervisorbilar.
Vi brydde oss inte så mycket om namnet på filsystemet och kallade det kortfattat ARDFS (gissa vad det står för))
Den här prototypen såg bra ut (inte visuellt, naturligtvis, det fanns ingen visuell design än) och visade bra resultat vad gäller prestanda och skalning. Efter det första riktiga resultatet satte vi igång det här projektet, organiserade en fullfjädrad utvecklingsmiljö och ett separat team som bara sysslade med vAIR.
Just vid den tiden hade lösningens allmänna arkitektur mognat, som ännu inte har genomgått några större förändringar.
Dyk in i ARDFS-filsystemet
ARDFS är grunden för vAIR, som tillhandahåller distribuerad, feltolerant datalagring över hela klustret. En av (men inte den enda) utmärkande egenskaperna hos ARDFS är att den inte använder några extra dedikerade servrar för metadata och hantering. Detta var ursprungligen tänkt för att förenkla konfigurationen av lösningen och för dess tillförlitlighet.
Förvaringsstruktur
Inom alla noder i klustret organiserar ARDFS en logisk pool från allt tillgängligt diskutrymme. Det är viktigt att förstå att en pool ännu inte är data eller formaterat utrymme, utan helt enkelt uppmärkning, dvs. Alla noder med vAIR installerat, när de läggs till i klustret, läggs automatiskt till i den delade ARDFS-poolen och diskresurser delas automatiskt över hela klustret (och tillgängliga för framtida datalagring). Detta tillvägagångssätt låter dig lägga till och ta bort noder i farten utan någon allvarlig inverkan på det redan körande systemet. De där. systemet är mycket lätt att skala "i tegelstenar", lägga till eller ta bort noder i klustret om det behövs.
Virtuella diskar (lagringsobjekt för virtuella maskiner) läggs till ovanpå ARDFS-poolen, som är byggda av virtuella block på 4 megabyte i storlek. Virtuella diskar lagrar data direkt. Feltoleransschemat är också inställt på den virtuella disknivån.
Som du kanske redan har gissat använder vi inte konceptet RAID (Redundant array of independent Disks) för feltolerans för diskundersystemet, utan RAIN (Redundant array of independent Nodes). De där. Feltolerans mäts, automatiseras och hanteras baserat på noderna, inte diskarna. Diskar är naturligtvis också ett lagringsobjekt, de övervakas, precis som allt annat, du kan utföra alla standardoperationer med dem, inklusive att montera en lokal hårdvaru-RAID, men klustret fungerar specifikt på noder.
I en situation där du verkligen vill ha RAID (till exempel ett scenario som stöder flera fel på små kluster) hindrar ingenting dig från att använda lokala RAID-kontroller och bygga utsträckt lagring och en RAIN-arkitektur ovanpå. Detta scenario är ganska live och stöds av oss, så vi kommer att prata om det i en artikel om typiska scenarier för att använda vAIR.
Feltoleransscheman för lagring
Det kan finnas två feltoleransscheman för virtuella diskar i vAIR:
1) Replikationsfaktor eller helt enkelt replikering - denna feltoleransmetod är lika enkel som en pinne och ett rep. Synkron replikering utförs mellan noder med en faktor på 2 (2 kopior per kluster) respektive 3 (3 kopior). RF-2 tillåter en virtuell disk att motstå fel i en nod i klustret, men "äter" hälften av den användbara volymen, och RF-3 kommer att motstå fel på 2 noder i klustret, men reserverar 2/3 av användbar volym för sina behov. Det här schemat är mycket likt RAID-1, det vill säga en virtuell disk som är konfigurerad i RF-2 är motståndskraftig mot fel på en nod i klustret. I det här fallet kommer allt att vara bra med data och även I/O kommer inte att sluta. När den fallna noden återgår till tjänst kommer automatisk dataåterställning/synkronisering att börja.
Nedan finns exempel på distribution av RF-2- och RF-3-data i normalt läge och i en felsituation.
Vi har en virtuell maskin med en kapacitet på 8MB unik (användbar) data, som körs på 4 vAIR-noder. Det är tydligt att det i verkligheten är osannolikt att det kommer att finnas en så liten volym, men för ett schema som återspeglar logiken i ARDFS-driften är detta exempel det mest förståeliga. AB är 4MB virtuella block som innehåller unik virtuell maskindata. RF-2 skapar två kopior av dessa block A1+A2 respektive B1+B2. Dessa block är "lagda" över noder och undviker skärningspunkten mellan samma data på samma nod, det vill säga kopian A1 kommer inte att finnas på samma nod som kopian A2. Samma med B1 och B2.
Om en av noderna misslyckas (till exempel nod nr 3, som innehåller en kopia av B1), aktiveras denna kopia automatiskt på noden där det inte finns någon kopia av dess kopia (det vill säga en kopia av B2).
Således kan den virtuella disken (och VM, följaktligen) lätt överleva felet i en nod i RF-2-schemat.
Replikeringsschemat, även om det är enkelt och pålitligt, lider av samma problem som RAID1 - inte tillräckligt med användbart utrymme.
2) Raderingskodning eller raderingskodning (även känd som "redundant kodning", "raderingskodning" eller "redundanskod") finns för att lösa problemet ovan. EC är ett redundansschema som ger hög datatillgänglighet med lägre diskutrymmeskostnader jämfört med replikering. Funktionsprincipen för denna mekanism liknar RAID 5, 6, 6P.
Vid kodning delar EC-processen upp ett virtuellt block (4MB som standard) i flera mindre "databitar" beroende på EC-schemat (till exempel delar ett 2+1-schema upp varje 4MB-block i 2 2MB-bitar). Därefter genererar denna process "paritetsbitar" för "databitar" som inte är större än en av de tidigare uppdelade delarna. Vid avkodning genererar EC de saknade bitarna genom att läsa "överlevande" data över hela klustret.
Till exempel kommer en virtuell disk med ett 2 + 1 EC-schema, implementerat på 4 klusternoder, lätt att motstå felet i en nod i klustret på samma sätt som RF-2. I det här fallet kommer omkostnadskostnaderna att vara lägre, i synnerhet är den användbara kapacitetskoefficienten för RF-2 2 och för EC 2+1 blir den 1,5.
För att beskriva det enklare är essensen att det virtuella blocket är uppdelat i 2-8 (varför från 2 till 8, se nedan) "bitar", och för dessa bitar beräknas "bitar" av paritet med en liknande volym.
Som ett resultat är data och paritet jämnt fördelade över alla noder i klustret. Samtidigt, som med replikering, distribuerar ARDFS automatiskt data över noder på ett sådant sätt att identiska data (kopior av data och deras paritet) förhindras från att lagras på samma nod, för att eliminera risken för att förlora data pga. till det faktum att datan och deras paritet plötsligt kommer att hamna på en lagringsnod som misslyckas.
Nedan är ett exempel, med samma 8 MB virtuella maskin och 4 noder, men med ett EC 2+1-schema.
Block A och B är uppdelade i två bitar på 2 MB vardera (två eftersom 2+1), det vill säga A1+A2 och B1+B2. Till skillnad från en replik är A1 inte en kopia av A2, det är ett virtuellt block A, uppdelat i två delar, samma sak som block B. Totalt får vi två uppsättningar på 4MB som var och en innehåller två två MB bitar. Därefter, för var och en av dessa uppsättningar, beräknas paritet med en volym på högst en bit (dvs. 2 MB), vi får ytterligare + 2 bitar av paritet (AP och BP). Totalt har vi 4×2 data + 2×2 paritet.
Därefter "läggs delarna ut" bland noderna så att data inte korsar deras paritet. De där. A1 och A2 kommer inte att vara på samma nod som AP.
I händelse av ett fel på en nod (till exempel även den tredje) kommer det fallna blocket B1 automatiskt att återställas från BP-pariteten, som är lagrad på nod nr 2, och kommer att aktiveras på den nod där det finns ingen B-paritet, dvs. bit av BP. I det här exemplet är detta nod nr 1
Jag är säker på att läsaren har en fråga:
"Allt du beskrev har länge implementerats både av konkurrenter och i lösningar med öppen källkod, vad är skillnaden mellan din implementering av EC i ARDFS?"
Och så kommer det att finnas intressanta funktioner i ARDFS.
Radera kodning med fokus på flexibilitet
Från början tillhandahöll vi ett ganska flexibelt EC X+Y-schema, där X är lika med ett tal från 2 till 8, och Y är lika med ett tal från 1 till 8, men alltid mindre än eller lika med X. Detta schema tillhandahålls för flexibilitet. Att öka antalet databitar (X) i vilka det virtuella blocket är uppdelat gör det möjligt att minska overheadkostnaderna, det vill säga öka det användbara utrymmet.
Att öka antalet paritetsbitar (Y) ökar tillförlitligheten hos den virtuella disken. Ju högre Y-värde, desto fler noder i klustret kan misslyckas. Att öka paritetsvolymen minskar naturligtvis mängden användbar kapacitet, men detta är ett pris att betala för tillförlitlighet.
Prestandaberoendet av EC-kretsar är nästan direkt: ju fler "bitar", desto lägre prestanda, här behövs naturligtvis en balanserad syn.
Detta tillvägagångssätt tillåter administratörer att konfigurera utdragen lagring med maximal flexibilitet. Inom ARDFS-poolen kan du använda alla feltoleransscheman och deras kombinationer, vilket, enligt vår mening, också är mycket användbart.
Nedan finns en tabell som jämför flera (inte alla möjliga) RF- och EC-scheman.
Tabellen visar att även den mest "frotté" kombinationen EC 8+7, som tillåter förlust av upp till 7 noder i ett kluster samtidigt, "äter" mindre användbart utrymme (1,875 mot 2) än standardreplikering och skyddar 7 gånger bättre , vilket gör denna skyddsmekanism, även om den är mer komplex, mycket mer attraktiv i situationer där det är nödvändigt att säkerställa maximal tillförlitlighet under förhållanden med begränsat diskutrymme. Samtidigt måste du förstå att varje "plus" till X eller Y kommer att vara en extra prestandaoverhead, så i triangeln mellan tillförlitlighet, besparingar och prestanda måste du välja mycket noggrant. Av denna anledning kommer vi att ägna en separat artikel till radering av kodningsstorlek.
Filsystemets tillförlitlighet och autonomi
ARDFS körs lokalt på alla noder i klustret och synkroniserar dem med sina egna medel genom dedikerade Ethernet-gränssnitt. Den viktiga punkten är att ARDFS oberoende synkroniserar inte bara data utan även metadata relaterad till lagring. Under arbetet med ARDFS studerade vi samtidigt ett antal befintliga lösningar och vi upptäckte att många synkroniserar filsystemets meta med hjälp av en extern distribuerad DBMS, som vi också använder för synkronisering, men bara konfigurationer, inte FS-metadata (om detta och andra relaterade delsystem i nästa artikel).
Att synkronisera FS-metadata med hjälp av en extern DBMS är naturligtvis en fungerande lösning, men då skulle konsistensen av data som lagras på ARDFS bero på den externa DBMS och dess beteende (och, ärligt talat, det är en nyckfull dam), som i vår åsikt är dålig. Varför? Om FS-metadata skadas kan FS-data i sig också sägas "adjö", så vi bestämde oss för att ta en mer komplex men tillförlitlig väg.
Vi har gjort metadatasynkroniseringsundersystemet för ARDFS själva, och det lever helt oberoende av intilliggande delsystem. De där. inget annat undersystem kan korrumpera ARDFS-data. Enligt vår mening är detta det mest tillförlitliga och korrekta sättet, men tiden får utvisa om det verkligen är så. Dessutom finns det ytterligare en fördel med detta tillvägagångssätt. ARDFS kan användas oberoende av vAIR, precis som sträckt förvaring, vilket vi säkert kommer att använda i framtida produkter.
Som ett resultat, genom att utveckla ARDFS, fick vi ett flexibelt och pålitligt filsystem som ger ett val där du kan spara på kapacitet eller ge upp allt på prestanda, eller göra ultratillförlitlig lagring till en rimlig kostnad, men minska prestandakraven.
Tillsammans med en enkel licenspolicy och en flexibel leveransmodell (framöver licensieras vAIR av nod, och levereras antingen som mjukvara eller som ett mjukvarupaket), gör detta att du kan skräddarsy lösningen mycket exakt efter en mängd olika kundkrav och bibehåll sedan lätt denna balans.
Vem behöver detta mirakel?
Å ena sidan kan vi säga att det redan finns aktörer på marknaden som har seriösa lösningar inom hyperkonvergensområdet, och det är dit vi faktiskt är på väg. Det verkar som att detta påstående är sant, MEN...
När vi däremot går ut i fält och kommunicerar med kunder ser vi och våra partners att så inte alls är fallet. Det finns många uppgifter för hyperkonvergens, på vissa ställen visste folk helt enkelt inte att sådana lösningar fanns, på andra verkade det dyra, på andra var det misslyckade tester av alternativa lösningar, och på andra förbjuder de köp alls på grund av sanktioner. I allmänhet visade sig fältet vara oplogat, så vi gick för att odla jungfrulig jord))).
När är lagringssystem bättre än GKS?
När vi arbetar med marknaden får vi ofta frågan när det är bättre att använda ett klassiskt schema med lagringssystem, och när man ska använda hyperkonvergent? Många företag som producerar GCS (särskilt de som inte har lagringssystem i sin portfölj) säger: "Lagringssystem blir föråldrade, endast hyperkonvergerade!" Detta är ett djärvt uttalande, men det återspeglar inte helt verkligheten.
I själva verket går lagringsmarknaden verkligen mot hyperkonvergens och liknande lösningar, men det finns alltid ett "men".
För det första kan datacenter och IT-infrastrukturer byggda enligt det klassiska schemat med lagringssystem inte enkelt byggas om, så moderniseringen och färdigställandet av sådana infrastrukturer är fortfarande ett arv i 5-7 år.
För det andra, den infrastruktur som för närvarande byggs till största delen (vilket betyder Ryska federationen) är byggd enligt det klassiska schemat med lagringssystem, och inte för att folk inte känner till hyperkonvergens, utan för att hyperkonvergensmarknaden är ny, lösningar och standarder har ännu inte fastställts, IT-personal är ännu inte utbildade, de har liten erfarenhet, men de behöver bygga datacenter här och nu. Och denna trend kommer att pågå i ytterligare 3-5 år (och sedan ytterligare ett arv, se punkt 1).
För det tredje finns det en rent teknisk begränsning i ytterligare små fördröjningar på 2 millisekunder per skrivning (exklusive den lokala cachen förstås), vilket är kostnaden för distribuerad lagring.
Tja, låt oss inte glömma användningen av stora fysiska servrar som älskar vertikal skalning av diskundersystemet.
Det finns många nödvändiga och populära uppgifter där lagringssystem beter sig bättre än GCS. Här kommer naturligtvis de tillverkare som inte har lagringssystem i sin produktportfölj inte hålla med oss, men vi är redo att argumentera rimligt. Naturligtvis kommer vi, som utvecklare av båda produkterna, definitivt att jämföra lagringssystem och GCS i en av våra framtida publikationer, där vi tydligt kommer att visa vilken som är bättre under vilka förhållanden.
Och var kommer hyperkonvergerade lösningar att fungera bättre än lagringssystem?
Utifrån punkterna ovan kan tre uppenbara slutsatser dras:
- Där ytterligare 2 millisekunders latens för inspelning, som konsekvent förekommer i vilken produkt som helst (nu pratar vi inte om syntetiska, nanosekunder kan visas på syntetiska), är okritiska, är hyperkonvergent lämpligt.
- Där belastningen från stora fysiska servrar kan omvandlas till många små virtuella och fördelas mellan noder, kommer hyperkonvergens också att fungera bra där.
- Där horisontell skalning har högre prioritet än vertikal skalning, kommer GCS att klara sig bra även där.
Vilka är dessa lösningar?
- Alla standardtjänster för infrastruktur (katalogtjänst, mail, EDMS, filservrar, små eller medelstora ERP- och BI-system, etc.). Vi kallar detta "allmän datoranvändning".
- Infrastrukturen för molnleverantörer, där det är nödvändigt att snabbt och standardiserat horisontellt expandera och enkelt "klippa" ett stort antal virtuella maskiner för klienter.
- Virtuell skrivbordsinfrastruktur (VDI), där många virtuella datorer för små användare körs och tyst "svävar" inom ett enhetligt kluster.
- Filialnätverk, där varje filial behöver en standard, feltolerant men billig infrastruktur med 15-20 virtuella maskiner.
- All distribuerad datoranvändning (big data-tjänster, till exempel). Där lasten inte går "på djupet", utan "på bredden".
- Testmiljöer där ytterligare små förseningar är acceptabla, men det finns budgetrestriktioner, eftersom dessa är tester.
För tillfället är det för dessa uppgifter som vi har gjort AERODISK vAIR och det är på dem vi fokuserar (framgångsrikt hittills). Kanske kommer detta att ändras snart, för... världen står inte stilla.
Så…
Detta avslutar den första delen av en stor serie artiklar; i nästa artikel kommer vi att prata om lösningens arkitektur och de komponenter som används.
Vi välkomnar frågor, förslag och konstruktiva tvister.
Källa: will.com