Hei, Habr-lesere. Med denne artikkelen åpner vi en serie som vil snakke om det hyperkonvergerte systemet AERODISK vAIR som vi har utviklet. I utgangspunktet ønsket vi å fortelle alt om alt i den første artikkelen, men systemet er ganske komplekst, så vi vil spise elefanten i deler.
La oss starte historien med historien om opprettelsen av systemet, fordype oss i ARDFS-filsystemet, som er grunnlaget for vAIR, og også snakke litt om plasseringen av denne løsningen på det russiske markedet.
I fremtidige artikler vil vi snakke mer detaljert om forskjellige arkitektoniske komponenter (klynge, hypervisor, lastbalanser, overvåkingssystem osv.), konfigurasjonsprosessen, ta opp lisensieringsproblemer, vise krasjtester separat og selvfølgelig skrive om lasttesting og dimensjonering. Vi vil også vie en egen artikkel til fellesskapsversjonen av vAIR.
Er Aerodisk en historie om lagringssystemer? Eller hvorfor begynte vi å gjøre hyperkonvergens i utgangspunktet?
Opprinnelig kom ideen om å skape vår egen hyperkonvergens til oss et sted rundt 2010. På den tiden fantes det verken Aerodisk eller lignende løsninger (kommersielle boksede hyperkonvergerte systemer) på markedet. Vår oppgave var følgende: fra et sett med servere med lokale disker, forent av en sammenkobling via Ethernet-protokollen, var det nødvendig å opprette en utvidet lagring og starte virtuelle maskiner og et programvarenettverk der. Alt dette måtte implementeres uten lagringssystemer (fordi det rett og slett ikke var penger til lagringssystemer og maskinvare, og vi hadde ennå ikke oppfunnet våre egne lagringssystemer).
Vi prøvde mange åpen kildekode-løsninger og løste til slutt dette problemet, men løsningen var veldig kompleks og vanskelig å gjenta. Dessuten var denne løsningen i kategorien «Fungerer det? Ikke rør! Derfor, etter å ha løst det problemet, videreutviklet vi ikke ideen om å forvandle resultatet av arbeidet vårt til et fullverdig produkt.
Etter den hendelsen gikk vi bort fra denne ideen, men vi hadde fortsatt følelsen av at dette problemet var fullstendig løsbart, og fordelene med en slik løsning var mer enn åpenbare. Deretter bekreftet de utgitte HCI-produktene fra utenlandske selskaper bare denne følelsen.
Derfor, i midten av 2016, gikk vi tilbake til denne oppgaven som en del av å lage et fullverdig produkt. På det tidspunktet hadde vi ennå ikke noen relasjoner med investorer, så vi måtte kjøpe en utviklingsstand for våre egne ikke veldig store penger. Etter å ha samlet brukte servere og brytere på Avito, gikk vi i gang.
Hovedoppgaven var å lage vårt eget, om enn enkle, men vårt eget filsystem, som automatisk og jevnt kunne distribuere data i form av virtuelle blokker på det n-te antallet klyngenoder, som er forbundet med en sammenkobling via Ethernet. Samtidig skal FS skalere godt og enkelt og være uavhengig av tilstøtende systemer, dvs. være fremmedgjort fra vAIR i form av «bare et lagringsanlegg».
Første vAIR-konsept
Vi forlot bevisst bruken av ferdige open source-løsninger for organisering av strukket lagring (ceph, gluster, luster og lignende) til fordel for vår egen utvikling, siden vi allerede hadde mye prosjekterfaring med dem. Selvfølgelig er disse løsningene i seg selv utmerket, og før vi jobbet med Aerodisk implementerte vi mer enn ett integrasjonsprosjekt med dem. Men det er én ting å implementere en spesifikk oppgave for én kunde, lære opp personalet og kanskje kjøpe støtte fra en stor leverandør, og en helt annen ting å lage et enkelt replikert produkt som skal brukes til ulike oppgaver, som vi som en leverandør, kan til og med vite om oss selv, vi vil ikke. For det andre formålet var ikke eksisterende åpen kildekode-produkter egnet for oss, så vi bestemte oss for å lage et distribuert filsystem selv.
To år senere oppnådde flere utviklere (som kombinerte arbeidet med vAIR med arbeidet med det klassiske Engine-lagringssystemet) et visst resultat.
I 2018 hadde vi skrevet et enkelt filsystem og supplert det med nødvendig maskinvare. Systemet kombinerte fysiske (lokale) disker fra forskjellige servere til ett flatt basseng via en intern sammenkobling og "kuttet" dem i virtuelle blokker, deretter ble blokkenheter med ulik grad av feiltoleranse opprettet fra de virtuelle blokkene, som virtuelle ble opprettet på. og utført ved hjelp av KVM hypervisor-biler.
Vi brydde oss ikke for mye med navnet på filsystemet og kalte det kort og godt ARDFS (gjett hva det står for))
Denne prototypen så bra ut (ikke visuelt, selvfølgelig, det var ingen visuell design ennå) og viste gode resultater når det gjelder ytelse og skalering. Etter det første virkelige resultatet satte vi dette prosjektet i gang, organiserte et fullverdig utviklingsmiljø og et eget team som kun tok for seg vAIR.
Akkurat på det tidspunktet hadde den generelle arkitekturen til løsningen modnet, som ennå ikke har gjennomgått store endringer.
Dykke inn i ARDFS-filsystemet
ARDFS er grunnlaget for vAIR, som gir distribuert, feiltolerant datalagring over hele klyngen. En av (men ikke den eneste) karakteristiske trekk ved ARDFS er at den ikke bruker noen ekstra dedikerte servere for metadata og administrasjon. Dette ble opprinnelig laget for å forenkle konfigurasjonen av løsningen og for dens pålitelighet.
Lagringsstruktur
Innenfor alle noder i klyngen organiserer ARDFS et logisk basseng fra all tilgjengelig diskplass. Det er viktig å forstå at en pool ennå ikke er data eller formatert plass, men ganske enkelt markering, dvs. Eventuelle noder med vAIR installert, når de legges til klyngen, legges automatisk til den delte ARDFS-poolen, og diskressurser blir automatisk delt på tvers av hele klyngen (og tilgjengelig for fremtidig datalagring). Denne tilnærmingen lar deg legge til og fjerne noder i farten uten noen alvorlig innvirkning på systemet som allerede kjører. De. systemet er veldig enkelt å skalere "i klosser", legge til eller fjerne noder i klyngen om nødvendig.
Virtuelle disker (lagringsobjekter for virtuelle maskiner) legges på toppen av ARDFS-bassenget, som er bygget av virtuelle blokker på 4 megabyte i størrelse. Virtuelle disker lagrer data direkte. Feiltoleranseskjemaet er også satt på det virtuelle disknivået.
Som du kanskje allerede har gjettet, for feiltoleranse for diskundersystemet, bruker vi ikke konseptet RAID (Redundant array of independent Disks), men bruker RAIN (Redundant array of independent Nodes). De. Feiltoleranse måles, automatiseres og administreres basert på nodene, ikke diskene. Disker er selvfølgelig også et lagringsobjekt, de, som alt annet, overvåkes, du kan utføre alle standardoperasjoner med dem, inkludert å sette sammen en lokal maskinvare-RAID, men klyngen opererer spesifikt på noder.
I en situasjon der du virkelig vil ha RAID (for eksempel et scenario som støtter flere feil på små klynger), er det ingenting som hindrer deg i å bruke lokale RAID-kontrollere, og bygge strukket lagring og en RAIN-arkitektur på toppen. Dette scenariet er ganske live og støttes av oss, så vi vil snakke om det i en artikkel om typiske scenarier for bruk av vAIR.
Lagringsfeiltoleranseskjemaer
Det kan være to feiltoleranseskjemaer for virtuelle disker i vAIR:
1) Replikeringsfaktor eller rett og slett replikering - denne metoden for feiltoleranse er like enkel som en stokk og et tau. Synkron replikering utføres mellom noder med en faktor på henholdsvis 2 (2 kopier per klynge) eller 3 (3 kopier). RF-2 lar en virtuell disk tåle svikt i én node i klyngen, men "spiser" halvparten av det nyttige volumet, og RF-3 vil tåle svikt i 2 noder i klyngen, men reserverer 2/3 av nyttig volum for sine behov. Dette opplegget er veldig likt RAID-1, det vil si at en virtuell disk konfigurert i RF-2 er motstandsdyktig mot feil på en node i klyngen. I dette tilfellet vil alt være bra med dataene og til og med I/O vil ikke stoppe. Når den falne noden kommer tilbake til tjeneste, vil automatisk datagjenoppretting/synkronisering begynne.
Nedenfor er eksempler på distribusjon av RF-2 og RF-3 data i normal modus og i en feilsituasjon.
Vi har en virtuell maskin med en kapasitet på 8MB unike (nyttige) data, som kjører på 4 vAIR-noder. Det er klart at det i realiteten er usannsynlig at det vil være et så lite volum, men for et opplegg som gjenspeiler logikken til ARDFS-operasjonen, er dette eksemplet det mest forståelige. AB er virtuelle blokker på 4 MB som inneholder unike virtuelle maskindata. RF-2 lager to kopier av disse blokkene A1+A2 og B1+B2, henholdsvis. Disse blokkene er "lagt ut" på tvers av noder, og unngår skjæringspunktet mellom de samme dataene på samme node, det vil si at kopi A1 ikke vil være plassert på samme node som kopi A2. Samme med B1 og B2.
Hvis en av nodene svikter (for eksempel node nr. 3, som inneholder en kopi av B1), aktiveres denne kopien automatisk på noden der det ikke er noen kopi av kopien (det vil si en kopi av B2).
Dermed kan den virtuelle disken (og VM, følgelig) enkelt overleve feilen til en node i RF-2-skjemaet.
Selv om replikeringsskjemaet er enkelt og pålitelig, lider det av det samme problemet som RAID1 - ikke nok brukbar plass.
2) Slettekoding eller slettekoding (også kjent som "redundant koding", "slettekoding" eller "redundanskode") finnes for å løse problemet ovenfor. EC er en redundansordning som gir høy datatilgjengelighet med lavere diskplassoverhead sammenlignet med replikering. Driftsprinsippet til denne mekanismen ligner på RAID 5, 6, 6P.
Ved koding deler EC-prosessen en virtuell blokk (4MB som standard) i flere mindre "databiter" avhengig av EC-skjemaet (for eksempel deler et 2+1-skjema hver 4MB-blokk i 2 2MB-biter). Deretter genererer denne prosessen "paritetsbiter" for "databitene" som ikke er større enn en av de tidligere delte delene. Ved dekoding genererer EC de manglende delene ved å lese de "overlevende" dataene over hele klyngen.
For eksempel vil en virtuell disk med et 2 + 1 EC-skjema, implementert på 4 klyngenoder, enkelt tåle feilen til en node i klyngen på samme måte som RF-2. I dette tilfellet vil overheadkostnadene være lavere, spesielt er den nyttige kapasitetskoeffisienten for RF-2 2, og for EC 2+1 vil den være 1,5.
For å beskrive det enklere, er essensen at den virtuelle blokken er delt inn i 2-8 (hvorfor fra 2 til 8, se nedenfor) "stykker", og for disse stykkene beregnes "stykker" av paritet med et lignende volum.
Som et resultat er data og paritet jevnt fordelt over alle noder i klyngen. Samtidig, som med replikering, distribuerer ARDFS automatisk data mellom noder på en slik måte at det forhindrer at identiske data (kopier av data og deres paritet) lagres på samme node, for å eliminere sjansen for å miste data pga. til det faktum at dataene og deres paritet plutselig vil havne på én lagringsnode som svikter.
Nedenfor er et eksempel, med samme 8 MB virtuelle maskin og 4 noder, men med et EC 2+1-skjema.
Blokkene A og B er delt inn i to stykker på 2 MB hver (to fordi 2+1), det vil si A1+A2 og B1+B2. I motsetning til en replika er ikke A1 en kopi av A2, det er en virtuell blokk A, delt i to deler, det samme med blokk B. Totalt får vi to sett på 4MB, som hver inneholder to to-MB-biter. Deretter, for hvert av disse settene, beregnes paritet med et volum på ikke mer enn ett stykke (dvs. 2 MB), vi får ytterligere + 2 stykker paritet (AP og BP). Totalt har vi 4×2 data + 2×2 paritet.
Deretter blir brikkene "lagt ut" blant nodene slik at dataene ikke skjærer hverandre med pariteten deres. De. A1 og A2 vil ikke være på samme node som AP.
Ved svikt i en node (for eksempel også den tredje), vil den fallne blokken B1 automatisk gjenopprettes fra BP-pariteten, som er lagret på node nr. 2, og aktiveres på noden der det er ingen B-paritet, dvs. stykke BP. I dette eksemplet er dette node nr. 1
Jeg er sikker på at leseren har et spørsmål:
"Alt du beskrev har lenge vært implementert både av konkurrenter og i åpen kildekode-løsninger, hva er forskjellen mellom implementeringen av EC i ARDFS?"
Og så vil det være interessante funksjoner ved ARDFS.
Slettekoding med fokus på fleksibilitet
Til å begynne med ga vi et ganske fleksibelt EC X+Y-skjema, der X er lik et tall fra 2 til 8, og Y er lik et tall fra 1 til 8, men alltid mindre enn eller lik X. Denne ordningen er gitt for fleksibilitet. Å øke antallet databiter (X) som den virtuelle blokken er delt inn i, gjør det mulig å redusere overheadkostnader, det vil si å øke brukbar plass.
Å øke antall paritetsbiter (Y) øker påliteligheten til den virtuelle disken. Jo større Y-verdi, desto flere noder i klyngen kan svikte. Å øke paritetsvolumet reduserer selvfølgelig mengden brukbar kapasitet, men dette er en pris å betale for pålitelighet.
Ytelsens avhengighet av EC-kretser er nesten direkte: jo flere "stykker", jo lavere ytelse; her er det selvfølgelig nødvendig med et balansert syn.
Denne tilnærmingen lar administratorer konfigurere strukket lagring med maksimal fleksibilitet. Innenfor ARDFS-bassenget kan du bruke alle feiltoleranseordninger og kombinasjoner av dem, noe som etter vår mening også er veldig nyttig.
Nedenfor er en tabell som sammenligner flere (ikke alle mulige) RF- og EC-ordninger.
Tabellen viser at selv den mest "frotté" kombinasjonen EC 8+7, som tillater tap av opptil 7 noder i en klynge samtidig, "spiser" mindre brukbar plass (1,875 versus 2) enn standard replikering, og beskytter 7 ganger bedre , noe som gjør denne beskyttelsesmekanismen, selv om den er mer kompleks, mye mer attraktiv i situasjoner der det er nødvendig å sikre maksimal pålitelighet under forhold med begrenset diskplass. Samtidig må du forstå at hvert "pluss" til X eller Y vil være en ekstra ytelsesoverhead, så i trekanten mellom pålitelighet, besparelser og ytelse må du velge veldig nøye. Av denne grunn vil vi vie en egen artikkel til sletting av kodingsstørrelser.
Pålitelighet og autonomi til filsystemet
ARDFS kjører lokalt på alle noder i klyngen og synkroniserer dem ved hjelp av egne midler gjennom dedikerte Ethernet-grensesnitt. Det viktige poenget er at ARDFS uavhengig synkroniserer ikke bare dataene, men også metadataene knyttet til lagring. Mens vi jobbet med ARDFS, studerte vi samtidig en rekke eksisterende løsninger og vi oppdaget at mange synkroniserer filsystemets meta ved hjelp av en ekstern distribuert DBMS, som vi også bruker til synkronisering, men kun konfigurasjoner, ikke FS-metadata (om dette og andre relaterte undersystemer). i neste artikkel).
Synkronisering av FS-metadata ved hjelp av en ekstern DBMS er selvfølgelig en fungerende løsning, men da vil konsistensen av dataene som er lagret på ARDFS avhenge av den eksterne DBMS og dens oppførsel (og ærlig talt, det er en lunefull dame), som i vår mening er dårlig. Hvorfor? Hvis FS-metadataene blir skadet, kan selve FS-dataene også sies "farvel", så vi bestemte oss for å ta en mer kompleks, men pålitelig vei.
Vi har laget metadatasynkroniseringsundersystemet for ARDFS selv, og det lever helt uavhengig av tilstøtende undersystemer. De. ingen andre undersystemer kan ødelegge ARDFS-data. Etter vår mening er dette den mest pålitelige og riktige måten, men tiden vil vise om det faktisk er slik. I tillegg er det en ekstra fordel med denne tilnærmingen. ARDFS kan brukes uavhengig av vAIR, akkurat som strukket lagring, som vi helt sikkert vil bruke i fremtidige produkter.
Som et resultat, ved å utvikle ARDFS, mottok vi et fleksibelt og pålitelig filsystem som gir et valg hvor du kan spare kapasitet eller gi opp alt på ytelse, eller lage ultrapålitelig lagring til en rimelig pris, men redusere ytelseskravene.
Sammen med en enkel lisensieringspolicy og en fleksibel leveringsmodell (i fremtiden er vAIR lisensiert av node, og leveres enten som programvare eller som en programvarepakke), lar dette deg skreddersy løsningen svært presist til en lang rekke kundekrav og deretter enkelt opprettholde denne balansen.
Hvem trenger dette miraklet?
På den ene siden kan vi si at det allerede er aktører på markedet som har seriøse løsninger innen hyperkonvergens, og det er dit vi faktisk er på vei. Det ser ut til at denne uttalelsen er sann, MEN...
Når vi derimot går ut i marka og kommuniserer med kunder, ser vi og våre samarbeidspartnere at det slett ikke er tilfelle. Det er mange oppgaver for hyperkonvergens, noen steder visste folk rett og slett ikke at slike løsninger fantes, andre virket det dyre, andre var det mislykkede tester av alternative løsninger, og andre steder forbyr de kjøp i det hele tatt på grunn av sanksjoner. Generelt viste feltet seg å være upløyd, så vi gikk for å heve jomfruelig jord))).
Når er lagringssystem bedre enn GKS?
Når vi jobber med markedet, blir vi ofte spurt om når det er bedre å bruke et klassisk opplegg med lagringssystemer, og når å bruke hyperkonvergent? Mange selskaper som produserer GCS (spesielt de som ikke har lagringssystemer i porteføljen) sier: "Lagringssystemer blir foreldet, kun hyperkonvergerte!" Dette er en dristig uttalelse, men den gjenspeiler ikke helt virkeligheten.
I sannhet beveger lagringsmarkedet seg mot hyperkonvergens og lignende løsninger, men det er alltid et "men".
For det første kan ikke datasentre og IT-infrastruktur bygget i henhold til den klassiske ordningen med lagringssystemer enkelt bygges om, så modernisering og ferdigstillelse av slike infrastrukturer er fortsatt en arv i 5-7 år.
For det andre er infrastrukturen som for tiden bygges for det meste (som betyr Den russiske føderasjonen) bygget i henhold til den klassiske ordningen ved bruk av lagringssystemer, og ikke fordi folk ikke vet om hyperkonvergens, men fordi hyperkonvergensmarkedet er nytt, løsninger og standarder er ennå ikke etablert, IT-folk er ennå ikke opplært, de har liten erfaring, men de må bygge datasentre her og nå. Og denne trenden vil vare i ytterligere 3-5 år (og deretter en annen arv, se punkt 1).
For det tredje er det en rent teknisk begrensning i ytterligere små forsinkelser på 2 millisekunder per skriving (utenom den lokale cachen, selvfølgelig), som er kostnaden for distribuert lagring.
Vel, la oss ikke glemme bruken av store fysiske servere som elsker vertikal skalering av diskundersystemet.
Det er mange nødvendige og populære oppgaver der lagringssystemer oppfører seg bedre enn GCS. Her vil selvfølgelig ikke de produsentene som ikke har lagringssystemer i produktporteføljen si seg enig med oss, men vi er klare til å argumentere rimelig. Selvfølgelig vil vi, som utviklere av begge produktene, definitivt sammenligne lagringssystemer og GCS i en av våre fremtidige publikasjoner, hvor vi tydelig vil demonstrere hvilken som er bedre under hvilke forhold.
Og hvor vil hyperkonvergerte løsninger fungere bedre enn lagringssystemer?
Basert på punktene ovenfor kan tre åpenbare konklusjoner trekkes:
- Der ytterligere 2 millisekunders ventetid for opptak, som konsekvent forekommer i ethvert produkt (nå snakker vi ikke om syntetiske stoffer, nanosekunder kan vises på syntetiske stoffer), er ukritisk, er hyperkonvergent egnet.
- Der belastningen fra store fysiske servere kan gjøres om til mange små virtuelle og fordeles mellom noder, vil hyperkonvergens også fungere bra der.
- Der horisontal skalering er en høyere prioritet enn vertikal skalering, vil GCS klare seg fint der også.
Hva er disse løsningene?
- Alle standard infrastrukturtjenester (katalogtjeneste, post, EDMS, filservere, små eller mellomstore ERP- og BI-systemer, etc.). Vi kaller dette "generell databehandling".
- Infrastrukturen til skyleverandører, hvor det er nødvendig å raskt og standardisert horisontalt utvide og enkelt "kutte" et stort antall virtuelle maskiner for klienter.
- Virtuell skrivebordsinfrastruktur (VDI), der mange virtuelle små brukermaskiner kjører og "flyter" stille innenfor en enhetlig klynge.
- Filialnettverk, der hver gren trenger en standard, feiltolerant, men rimelig infrastruktur på 15-20 virtuelle maskiner.
- All distribuert databehandling (for eksempel store datatjenester). Hvor lasten ikke går "i dybden", men "i bredden".
- Testmiljøer der ytterligere små forsinkelser er akseptable, men det er budsjettbegrensninger, fordi dette er tester.
For øyeblikket er det for disse oppgavene vi har laget AERODISK vAIR og det er på dem vi fokuserer (vellykket så langt). Kanskje dette endrer seg snart, fordi... verden står ikke stille.
Så…
Dette fullfører første del av en stor artikkelserie; i neste artikkel skal vi snakke om arkitekturen til løsningen og komponentene som brukes.
Vi tar gjerne imot spørsmål, forslag og konstruktive tvister.
Kilde: www.habr.com