Hallo Habr-lesers. Met hierdie artikel open ons 'n siklus wat sal praat oor die hipergekonvergeerde stelsel AERODISK vAIR wat deur ons ontwikkel is. Aanvanklik wou ons alles oor alles in die eerste artikel vertel, maar die stelsel is redelik ingewikkeld, so ons sal die olifant in dele eet.
Kom ons begin die storie met die geskiedenis van die skepping van die stelsel, delf in die ARDFS-lêerstelsel, wat die basis van vAIR is, en bespreek ook 'n bietjie oor die posisionering van hierdie oplossing op die Russiese mark.
In toekomstige artikels sal ons in meer besonderhede praat oor verskillende argitektoniese komponente (cluster, hiperviser, lasbalanseerder, moniteringstelsel, ens.), die konfigurasieproses, lisensiëringskwessies opper, botstoetse afsonderlik wys en, natuurlik, skryf oor lastoetsing en grootte. Ons sal ook 'n aparte artikel aan die gemeenskapsweergawe van vAIR wy.
Aerodisk is soos 'n storie oor bergingstelsels? Of hoekom het ons hoegenaamd hiperkonvergent begin?
Aanvanklik het die idee om ons eie hiperkonvergente te skep iewers rondom 2010 by ons gekom. Op daardie tydstip was daar nóg Aerodisk nóg soortgelyke oplossings (kommersiële boks-hipergekonvergeerde stelsels) op die mark. Ons taak was soos volg: vanaf 'n stel bedieners met plaaslike skywe, verbind deur 'n interkonneksie via die Ethernet-protokol, was dit nodig om 'n uitgebreide berging te maak en virtuele masjiene en 'n programnetwerk daar te laat loop. Dit alles moes sonder berging geïmplementeer word (omdat daar eenvoudig nie geld was vir berging en die vasmaak daarvan nie, en ons het nog nie ons bergingstelsel uitgevind nie).
Ons het baie oopbronoplossings probeer en steeds hierdie probleem opgelos, maar die oplossing was baie kompleks en moeilik om te herhaal. Boonop was hierdie oplossing uit die kategorie "Werke? Moenie aanraak nie!" Daarom, nadat ons die probleem opgelos het, het ons nie die idee verder ontwikkel om die resultaat van ons werk in 'n volwaardige produk te omskep nie.
Na daardie voorval het ons wegbeweeg van hierdie idee, maar ons het steeds die gevoel gehad dat hierdie taak heeltemal oplosbaar was, en die voordele van so 'n besluit was meer as voor die hand liggend. In die toekoms het HCI-produkte wat deur buitelandse maatskappye vrygestel is, net hierdie gevoel bevestig.
Daarom het ons in die middel van 2016 teruggekeer na hierdie taak as deel van die skepping van 'n volwaardige produk. Op daardie tydstip het ons geen verhoudings met beleggers gehad nie, so ons moes 'n ontwikkelingsstaander koop vir ons eie nie baie groot geld nie. Nadat ons BU-bedieners en skakelaars op Avito getik het, het ons begin werk.
Die belangrikste aanvanklike taak was om ons eie, alhoewel eenvoudig, maar ons eie lêerstelsel te skep, wat data outomaties en eweredig kon versprei in die vorm van virtuele blokke op die n-de aantal cluster nodusse, wat verbind is deur 'n Ethernet-interkonneksie. Terselfdertyd moet die FS goed en maklik skaal en onafhanklik wees van aangrensende stelsels, m.a.w. vervreem word van vAIR as "net berging".
Die eerste vAIR-konsep
Ons het doelbewus die gebruik van klaargemaakte oopbronoplossings vir die organisering van uitgerekte berging (ceph, gluster, glans en dies meer) laat vaar ten gunste van ons eie ontwikkeling, aangesien ons reeds baie projekervaring daarmee gehad het. Natuurlik is hierdie oplossings op sigself uitstekend, en voordat ons aan Aerodisk gewerk het, het ons meer as een integrasieprojek daarmee geïmplementeer. Maar dit is een ding om 'n spesifieke taak van een kliënt te implementeer, personeel op te lei en moontlik ondersteuning van 'n groot verskaffer te koop, en nog 'n ander ding is om 'n maklik repliseerbare produk te skep wat gebruik sal word vir verskeie take wat ons as 'n verskaffer, dalk selfs van onsself weet, ons sal nie. Vir die tweede doelwit het die bestaande oopbronprodukte ons nie gepas nie, daarom het ons besluit om self die verspreide lêerstelsel te sny.
Twee jaar later, met die hulp van verskeie ontwikkelaars (wat werk aan vAIR gekombineer het met werk aan die klassieke Storage Engine), het hulle 'n sekere resultaat behaal.
Teen 2018 het ons die eenvoudigste lêerstelsel geskryf en dit aangevul met die nodige binding. Die stelsel het fisiese (plaaslike) skywe vanaf verskillende bedieners in een plat poel gekombineer via 'n interne interkonneksie en dit in virtuele blokke "gesny", dan is bloktoestelle met verskillende grade van fouttoleransie geskep uit die virtuele blokke, waarop virtuele toestelle geskep is en uitgevoer met behulp van die KVM-hypervisor.-motors.
Ons het nie veel gesteur aan die naam van die lêerstelsel nie en het dit bondig ARDFS genoem (raai hoe dit staan))
Hierdie prototipe het goed gelyk (natuurlik nie visueel nie, daar was toe geen visuele ontwerp nie) en het goeie resultate getoon in terme van werkverrigting en skaal. Na die eerste werklike resultaat het ons hierdie projek van stapel gestuur, nadat ons reeds 'n volwaardige ontwikkelingsomgewing en 'n aparte span georganiseer het wat net met vAIR gehandel het.
Net teen daardie tyd het die algemene argitektuur van die oplossing volwasse geword, wat nog nie groot veranderinge ondergaan het nie.
Duik in die ARDFS-lêerstelsel
ARDFS is die ruggraat van vAIR, wat verspreide foutverdraagsame berging vir die hele groep bied. Een van (maar nie die enigste nie) onderskeidende kenmerke van ARDFS is dat dit geen bykomende toegewyde bedieners vir meta en bestuur gebruik nie. Dit is oorspronklik ontwerp om die konfigurasie van die oplossing en vir die betroubaarheid daarvan te vereenvoudig.
Bergingstruktuur
Binne alle cluster nodusse organiseer ARDFS 'n logiese poel vanaf alle beskikbare skyfspasie. Dit is belangrik om te verstaan dat die poel nog nie data of geformateerde spasie is nie, maar bloot opmaak, d.w.s. enige nodusse met vAIR geïnstalleer wanneer dit by die groep gevoeg word, word outomaties by die gedeelde ARDFS-poel gevoeg en skyfbronne word outomaties oor die hele groep gedeel (en beskikbaar vir toekomstige databerging). Hierdie benadering laat jou toe om nodusse dadelik by te voeg en te verwyder sonder enige ernstige impak op die reeds lopende stelsel. Dié. die stelsel is baie maklik om te skaal met "stene", voeg of verwyder nodusse in die cluster indien nodig.
Bo-op die ARDFS-poel word virtuele skywe (bergingsvoorwerpe vir virtuele masjiene) bygevoeg, wat gebou is uit virtuele blokke van 4 megagrepe groot. Data word direk op virtuele skywe gestoor. Die fouttoleransieskema word ook op die virtuele skyfvlak gestel.
Soos jy dalk geraai het, vir die fouttoleransie van die skyfsubstelsel, gebruik ons nie die konsep van RAID (Redundant array of independent Disks), maar gebruik RAIN (Redundant array of independent Nodes). Dié. fouttoleransie word gemeet, geoutomatiseer en bestuur in terme van nodusse, nie skywe nie. Skywe is natuurlik ook 'n stoorvoorwerp, hulle word, soos alles anders, gemonitor, u kan alle standaardbewerkings daarmee uitvoer, insluitend die bou van 'n plaaslike hardeware-RAID, maar die groep werk presies met nodusse.
In 'n situasie waar jy regtig RAID wil hê (byvoorbeeld 'n scenario wat veelvuldige mislukkings op klein groepe ondersteun), verhoed niks jou om plaaslike RAID-beheerders te gebruik nie, en boonop uitgerekte berging en 'n RAIN-argitektuur te doen. So 'n scenario is nogal lewendig en word deur ons ondersteun, so ons sal daaroor praat in 'n artikel oor tipiese scenario's vir die gebruik van vAIR.
Berging failover skemas
Daar kan twee fouttoleransieskemas vir virtuele skywe in vAIR wees:
1) Replikasie faktor of net replikasie - hierdie fouttoleransie metode is eenvoudig "soos 'n stok en 'n tou". Sinchroniese replikasie word uitgevoer tussen nodusse met 'n faktor van 2 (2 kopieë per cluster) of 3 (3 kopieë, onderskeidelik). RF-2 laat die virtuele skyf toe om die mislukking van een nodus in die groep te weerstaan, maar "vreet" die helfte van die bruikbare volume op, en RF-3 kan die mislukking van 2 nodusse in die groep weerstaan, maar behou reeds 2/3 van die bruikbare volume vir sy behoeftes. Hierdie skema is baie soortgelyk aan RAID-1, dit wil sê, 'n virtuele skyf wat in RF-2 gekonfigureer is, is bestand teen die mislukking van enige nodus van die groep. In hierdie geval sal die data in orde wees en selfs die I / O sal nie stop nie. Wanneer die afgelaaide nodus terugkeer na diens, sal outomatiese dataherwinning / sinchronisasie begin.
Hieronder is voorbeelde van verspreiding van RF-2- en RF-3-data in normale modus en in 'n mislukkingsituasie.
Ons het 'n virtuele masjien met 'n volume van 8MB unieke (nuttige) data, wat op 4 vAIR-nodusse loop. Dit is duidelik dat dit in werklikheid onwaarskynlik is dat daar so 'n klein volume sal wees, maar vir 'n skema wat die logika van ARDFS weerspieël, is hierdie voorbeeld die mees verstaanbare. AB's is 4MB virtuele blokke wat unieke virtuele masjiendata bevat. RF-2 skep twee kopieë van hierdie blokke A1+A2 en B1+B2, onderskeidelik. Hierdie blokke word in nodusse "ontbind" en vermy die kruising van dieselfde data op dieselfde nodus, dit wil sê, 'n kopie van A1 sal nie op dieselfde nodus as 'n kopie van A2 geleë wees nie. Met B1 en B2 is dit soortgelyk.
In die geval van 'n mislukking van een van die nodusse (byvoorbeeld nodus nr. 3, wat 'n kopie van B1 bevat), word hierdie kopie outomaties geaktiveer op die nodus waar daar geen kopie van sy kopie is nie (dit is 'n kopie van B2).
Dus sal die virtuele skyf (en VM, onderskeidelik) maklik die mislukking van een nodus in die RF-2-skema oorleef.
Die replikasieskema, ten spyte van sy eenvoud en betroubaarheid, ly aan dieselfde seer as RAID1 - daar is min bruikbare spasie.
2) Wiskodering of veekodering (ook bekend as "oortollige kodering", "uitwiskodering" of "oortolligheidskode") bestaan net om die probleem hierbo op te los. EC is 'n oortolligheidskema wat hoë databeskikbaarheid bied met minder skyfspasie bokoste in vergelyking met replikasie. Die beginsel van werking van hierdie meganisme is soortgelyk aan RAID 5, 6, 6P.
By enkodering verdeel die EC-proses 'n virtuele blok (verstek 4MB) in verskeie kleiner "databrokkies" afhangende van die EC-skema (byvoorbeeld, 'n 2+1-skema verdeel elke 4MB-blok in 2 2MB-stukke). Verder genereer hierdie proses "pariteitsstukke" vir "databrokkies" wat nie groter is as een van die voorheen geskeide stukke nie. By dekodering genereer EC die ontbrekende stukke deur die "oorlewende" data van die hele groep te lees.
Byvoorbeeld, 'n virtuele skyf met 'n 2 + 1 EC-skema geïmplementeer op 4 cluster nodusse sal maklik die mislukking van een knoop in die cluster oorleef op dieselfde manier as RF-2. Terselfdertyd sal oorhoofse koste laer wees, veral die nuttige kapasiteitsfaktor vir RF-2 is 2, en vir EC 2 + 1 sal dit 1,5 wees.
As dit makliker is om te beskryf, dan is die punt dat die virtuele blok in 2-8 (waarom van 2 tot 8 sien hieronder) "stukke" verdeel word, en vir hierdie stukke word pariteit "stukke" van 'n soortgelyke volume bereken.
Gevolglik word data en pariteit eweredig oor alle nodusse van die groepering versprei. Terselfdertyd, soos met replikasie, versprei ARDFS data outomaties tussen nodusse op so 'n manier dat die stoor van identiese data (kopieë van data en hul pariteit) op een nodus voorkom word, om sodoende die kans om data te verloor a.g.v. die feit dat die data en hul pariteit skielik op 'n enkele stoornodus sal beland wat sal misluk.
Hieronder is 'n voorbeeld, met dieselfde 8 MB virtuele masjien en 4 nodusse, maar met die EC 2 + 1 skema.
Blokke A en B word verdeel in twee stukke van 2 MB elk (twee omdat 2 + 1), dit wil sê in A1 + A2 en B1 + B2. Anders as 'n replika, is A1 nie 'n kopie van A2 nie, dit is 'n virtuele blok A, verdeel in twee dele, dieselfde met blok B. In totaal kry ons twee stelle van 4MB elk, wat elk twee twee-megagreep-stukke bevat . Verder, vir elk van hierdie stelle, word die pariteit bereken met 'n volume van nie meer as een stuk (d.w.s. 2 MB), ons kry 'n bykomende + 2 pariteitstukke (AP en BP). In totaal het ons 4×2 data + 2×2 pariteit.
Vervolgens word die stukke in nodusse "ontbind" sodat die data nie met hul pariteit sny nie. Dié. A1 en A2 sal nie op dieselfde nodus as die AP lê nie.
In die geval van 'n mislukking van een nodus (kom ons sê ook die derde een), sal die gevalle blok B1 outomaties herstel word vanaf die BP-pariteit, wat op nodus No. 2 gestoor is, en sal geaktiveer word op die nodus waar daar is geen B-pariteit, m.a.w. stukkie BP. In hierdie voorbeeld is dit nodus nommer 1
Ek is seker die leser wonder:
"Alles wat jy beskryf het, is lank reeds geïmplementeer deur mededingers en in oopbronoplossings, wat is die verskil tussen jou implementering van EC in ARDFS?"
En dan sal daar interessante kenmerke van die werk van ARDFS wees.
Vee kodering uit met 'n fokus op buigsaamheid
Aanvanklik het ons 'n taamlik buigsame EC X+Y-skema verskaf, waar X 'n getal van 2 tot 8 is, en Y 'n getal van 1 tot 8 is, maar altyd minder as of gelyk aan X. Hierdie skema word voorsien vir buigsaamheid. Deur die aantal stukke data (X) waarin die virtuele blok verdeel word, te vermeerder, kan u bokoste verminder, dit wil sê, die bruikbare spasie vergroot.
Die verhoging van die aantal pariteitsstukke (Y) verhoog die betroubaarheid van die virtuele skyf. Hoe groter die Y-waarde, hoe meer nodusse in die groep kan misluk. Natuurlik verminder die verhoging van die hoeveelheid pariteit die hoeveelheid bruikbare kapasiteit, maar dit is 'n afweging vir betroubaarheid.
Die afhanklikheid van prestasie van EG-skemas is byna direk: hoe meer "stukke", hoe laer die prestasie, hier is natuurlik 'n gebalanseerde siening nodig.
Hierdie benadering stel administrateurs in staat om die uitgerekte berging so buigsaam as moontlik te konfigureer. Binne die ARDFS-poel kan jy enige foutverdraagsaamheidskemas en hul kombinasies gebruik, wat na ons mening ook baie nuttig is.
Hieronder is 'n tabel wat verskeie (nie alle moontlike) RF- en EC-skemas vergelyk.
Die tabel toon dat selfs die mees "terry" kombinasie van EC 8 + 7, wat die verlies van tot 7 nodusse in 'n groep op dieselfde tyd toelaat, minder bruikbare spasie (1,875 vs. 2) as standaard replikasie "opvreet" , en beskerm 7 keer beter, wat hierdie beskermingsmeganisme maak, hoewel meer kompleks, maar baie aantrekliker in situasies waar jy maksimum betroubaarheid moet verseker in toestande van gebrek aan skyfspasie. Terselfdertyd moet jy verstaan dat elke "plus" aan X of Y 'n bykomende prestasie-bokoste sal wees, dus moet jy baie versigtig kies in die driehoek tussen betroubaarheid, ekonomie en prestasie. Om hierdie rede sal ons 'n aparte artikel wy aan die grootte van die uitvee van kodering.
Betroubaarheid en outonomie van die lêerstelsel
ARDFS loop plaaslik op alle cluster nodusse en sinchroniseer hulle op sy eie manier via toegewyde Ethernet-koppelvlakke. 'n Belangrike punt is dat ARDFS self nie net data sinchroniseer nie, maar ook metadata wat met berging verband hou. In die loop van die werk aan ARDFS het ons 'n aantal bestaande oplossings in parallel bestudeer en ons het gevind dat baie die meta-lêerstelsel sinchroniseer deur 'n eksterne verspreide DBMS te gebruik, wat ons ook gebruik om te sinchroniseer, maar slegs konfigurasies, en nie lêerstelsel-metadata nie ( oor hierdie en ander verwante substelsels in die volgende artikel).
Die sinchronisering van FS-metadata met behulp van 'n eksterne DBBS is natuurlik 'n werkende oplossing, maar dan sal die konsekwentheid van die data wat op ARDFS gestoor word afhang van die eksterne DBBS en sy gedrag (en eerlikwaar, sy is 'n wispelturige dame), wat in ons mening is sleg. Hoekom? As die FS-metadata beskadig word, kan die FS-data self ook totsiens gesê word, so ons het besluit om 'n meer ingewikkelde maar betroubare pad te neem.
Ons het die metadata-sinchronisasie-substelsel vir ARDFS op ons eie gemaak, en dit leef absoluut onafhanklik van aangrensende substelsels. Dié. geen ander substelsel kan ARDFS-data korrupteer nie. Na ons mening is dit die mees betroubare en korrekte manier, maar die tyd sal leer of dit werklik die geval is. Daarbenewens is daar met hierdie benadering 'n bykomende voordeel. ARDFS kan onafhanklik van vAIR gebruik word, net soos 'n uitgerekte stoor, wat ons beslis in toekomstige produkte sal gebruik.
As gevolg hiervan, deur ARDFS te ontwikkel, het ons 'n buigsame en betroubare lêerstelsel gekry wat 'n keuse gee waar u op kapasiteit kan bespaar of alles op werkverrigting kan gee, of berging ultrabetroubaar kan maak vir 'n beskeie koste, maar met laer werkverrigtingvereistes.
Saam met 'n eenvoudige lisensiëringsbeleid en 'n buigsame afleweringsmodel (as ons vorentoe kyk, word vAIR deur nodusse gelisensieer, en óf as sagteware óf as 'n PACK gelewer), maak dit dit moontlik om die oplossing te verfyn vir 'n verskeidenheid klantvereistes en maklik handhaaf hierdie balans in die toekoms.
Wie het hierdie wonderwerk nodig?
Aan die een kant kan ons sê dat daar reeds spelers op die mark is wat ernstige oplossings het op die gebied van hiperkonvergente, en waar ons eintlik klim. Hierdie stelling blyk waar te wees, MAAR...
Aan die ander kant, as ons in die veld uitgaan en met kliënte kommunikeer, sien ons en ons vennote dat dit glad nie die geval is nie. Daar is baie take vir hiperkonvergente, iewers het mense eenvoudig nie geweet dat sulke oplossings bestaan nie, iewers het dit duur gelyk, iewers was daar onsuksesvolle toetse van alternatiewe oplossings, en iewers is dit verbode om enigsins te koop, weens die sanksies. In die algemene veld het dit geblyk dat dit ontploeg was, so ons het maagdelike grond gaan grootmaak))).
Wanneer is berging beter as GKS?
In die loop van die werk met die mark word ons dikwels gevra wanneer dit beter is om die klassieke skema met stoorstelsels te gebruik, en wanneer is dit beter om hiperkonvergent te gebruik? Baie maatskappye wat GKS vervaardig (veral dié wat nie bergingstelsels in hul portefeulje het nie) sê: “SAN raak verouderd, net hiperkonvergent!”. Dit is 'n gewaagde stelling, maar dit weerspieël nie heeltemal die werklikheid nie.
Om die waarheid te sê, die bergingsmark beweeg inderdaad na hipergekonvergeerde en soortgelyke oplossings, maar daar is altyd 'n "maar".
Eerstens kan datasentrums en IT-infrastruktuur wat volgens die klassieke skema met berging gebou is nie so herbou word nie, so die modernisering en voltooiing van sulke infrastruktuur is steeds 'n nalatenskap vir 5-7 jaar.
Tweedens, die infrastruktuur wat nou vir die grootste deel gebou word (wat beteken die Russiese Federasie) word volgens die klassieke skema gebou deur bergingstelsels te gebruik, en nie omdat mense nie weet van hiperkonvergente nie, maar omdat die hiperkonvergente mark nuut is, oplossings en standaarde is nog nie vasgestel nie, IT-spesialiste is nog nie opgelei nie, daar is min ervaring, maar dit is nodig om datasentrums hier en nou te bou. En hierdie tendens is vir nog 3-5 jaar (en dan nog 'n nalatenskap, sien punt 1).
Derdens, 'n suiwer tegniese beperking in bykomende klein vertragings van 2 millisekondes per skryf (sonder om die plaaslike kas in ag te neem, natuurlik), wat 'n betaling vir verspreide berging is.
Wel, laat ons nie vergeet van die gebruik van groot fisiese bedieners wat van vertikale skaal van die skyfsubstelsel hou nie.
Daar is baie nodige en gewilde take waar die bergingstelsel beter optree as die GCS. Hier sal die vervaardigers wat nie bergingstelsels in hul produkportefeulje het natuurlik met ons saamstem nie, maar ons is gereed om met rede te argumenteer. Natuurlik sal ons, as die ontwikkelaars van beide produkte, in een van die toekomstige publikasies beslis stoorstelsels en GCS vergelyk, waar ons duidelik sal demonstreer wat beter is onder watter omstandighede.
En waar sal hipergekonvergeerde oplossings beter werk as berging?
Gebaseer op die tesis hierbo, kan drie ooglopende gevolgtrekkings gemaak word:
- Waar 'n bykomende 2 millisekondes se skryfvertraging, wat geleidelik in enige produk voorkom (nou praat ons nie van sintetiese stowwe nie, jy kan nanosekondes op sintetiese stowwe wys), nie krities is nie, is hiperkonvergent geskik.
- Waar die las van groot fisiese bedieners in baie klein virtuele bedieners verander kan word en tussen die nodusse versprei kan word, sal hiperkonvergensie ook goed daar werk.
- Waar horisontale skaal belangriker is as vertikale skaal, sal GKS ook goed daar werk.
Wat is hierdie oplossings?
- Alle standaard infrastruktuurdienste (gidsdiens, pos, EDMS, lêerbedieners, klein of medium ERP en BI-stelsels, ens.). Ons noem dit "algemene rekenaars".
- Wolkverskaffer-infrastruktuur waar dit nodig is om vinnig en horisontaal horisontaal uit te brei en maklik 'n groot aantal virtuele masjiene vir kliënte te "sny".
- Virtual Desktop Infrastructure (VDI), waar baie klein persoonlike virtuele masjiene begin en stilweg binne 'n eenvormige groepie "dryf".
- Taknetwerke, waar jy in elke tak 'n standaard, foutverdraagsame, maar terselfdertyd goedkoop infrastruktuur van 15-20 virtuele masjiene moet kry.
- Enige verspreide rekenaar (byvoorbeeld grootdatadienste). Waar die vrag nie "in diepte" is nie, maar "in die breedte".
- Toets omgewings waar bykomende klein vertragings aanvaarbaar is, maar daar is begrotingsbeperkings, want dit is toetse.
Op die oomblik is dit vir hierdie take wat ons AERODISK vAIR gemaak het en ons fokus daarop (tot dusver suksesvol). Miskien sal dit binnekort verander, want. die wêreld staan nie stil nie.
So…
Dit sluit die eerste deel van 'n groot reeks artikels af, in die volgende artikel sal ons praat oor die argitektuur van die oplossing en die komponente wat gebruik word.
Ons sal bly wees vir vrae, voorstelle en konstruktiewe geskille.
Bron: will.com