Përshëndetje, lexues të Habrit. Me këtë artikull ne hapim një seri që do të flasim për sistemin hiperkonvergjent AERODISK vAIR që kemi zhvilluar. Fillimisht, ne donim të tregonim gjithçka për gjithçka në artikullin e parë, por sistemi është mjaft kompleks, kështu që ne do ta hamë elefantin pjesë-pjesë.
Le ta fillojmë historinë me historinë e krijimit të sistemit, të gërmojmë në sistemin e skedarëve ARDFS, i cili është baza e vAIR, dhe gjithashtu të flasim pak për pozicionimin e kësaj zgjidhjeje në tregun rus.
Në artikujt e ardhshëm do të flasim më në detaje për komponentë të ndryshëm arkitekturorë (grup, hipervizor, balancues i ngarkesës, sistemi i monitorimit, etj.), Procesi i konfigurimit, ngritja e çështjeve të licencimit, shfaqja veçmas testet e përplasjes dhe, natyrisht, shkruajmë për testimin e ngarkesës dhe përmasat. Ne gjithashtu do t'i kushtojmë një artikull të veçantë versionit të komunitetit të vAIR.
A është Aerodisk një histori për sistemet e ruajtjes? Ose pse filluam të bëjmë hiperkonvergjencë në radhë të parë?
Fillimisht, ideja për të krijuar hiperkonvergjencën tonë na erdhi diku rreth vitit 2010. Në atë kohë, nuk kishte as Aerodisk dhe as zgjidhje të ngjashme (sisteme të hiperkonvergjuara me kuti komerciale) në treg. Detyra jonë ishte si vijon: nga një grup serverësh me disqe lokalë, të bashkuar nga një ndërlidhje përmes protokollit Ethernet, ishte e nevojshme të krijonim një ruajtje të zgjeruar dhe të nisnim makina virtuale dhe një rrjet softuerësh atje. E gjithë kjo duhej të zbatohej pa sisteme ruajtjeje (sepse thjesht nuk kishte para për sistemet e ruajtjes dhe pajisjet e tij, dhe ne nuk kishim shpikur ende sistemet tona të ruajtjes).
Provuam shumë zgjidhje me burim të hapur dhe më në fund e zgjidhëm këtë problem, por zgjidhja ishte shumë komplekse dhe e vështirë për t'u përsëritur. Përveç kësaj, kjo zgjidhje ishte në kategorinë e “A funksionon? Mos e prekni! Prandaj, pasi e zgjidhëm këtë problem, ne nuk e zhvilluam më tej idenë për të transformuar rezultatin e punës sonë në një produkt të plotë.
Pas atij incidenti, ne u larguam nga kjo ide, por përsëri kishim ndjenjën se ky problem ishte plotësisht i zgjidhshëm dhe përfitimet e një zgjidhjeje të tillë ishin më se të dukshme. Më pas, produktet e lëshuara HCI të kompanive të huaja vetëm konfirmuan këtë ndjenjë.
Prandaj, në mesin e vitit 2016, ne iu kthyem kësaj detyre si pjesë e krijimit të një produkti të plotë. Në atë kohë ne nuk kishim ende asnjë marrëdhënie me investitorët, ndaj na u desh të blinim një stendë zhvillimi për paratë tona jo shumë të mëdha. Pasi mblodhëm serverë të përdorur dhe çelsat në Avito, u nisëm në biznes.
Detyra kryesore fillestare ishte të krijonim sistemin tonë të skedarëve, megjithëse të thjeshtë, por të vetin, i cili mund të shpërndante automatikisht dhe në mënyrë të barabartë të dhënat në formën e blloqeve virtuale në numrin e n-të të nyjeve të grupimeve, të cilat lidhen me një ndërlidhje përmes Ethernetit. Në të njëjtën kohë, FS duhet të shkallëzohet mirë dhe lehtë dhe të jetë i pavarur nga sistemet ngjitur, d.m.th. të tjetërsohet nga vAIR në formën e "vetëm një objekti magazinimi".
Koncepti i parë VAIR
Ne braktisëm qëllimisht përdorimin e zgjidhjeve të gatshme me burim të hapur për organizimin e ruajtjes së zgjatur (ceph, gluster, shkëlqim dhe të ngjashme) në favor të zhvillimit tonë, pasi tashmë kishim shumë përvojë projekti me to. Sigurisht, vetë këto zgjidhje janë të shkëlqyera dhe përpara se të punonim në Aerodisk, ne kemi zbatuar më shumë se një projekt integrimi me ta. Por është një gjë të zbatosh një detyrë specifike për një klient, të trajnosh stafin dhe, ndoshta, të blesh mbështetjen e një shitësi të madh, dhe krejt tjetër gjë të krijosh një produkt lehtësisht të përsëritur që do të përdoret për detyra të ndryshme, të cilat ne, si shitësi, mund të dimë edhe për veten ne nuk do ta dimë. Për qëllimin e dytë, produktet ekzistuese me burim të hapur nuk ishin të përshtatshme për ne, kështu që vendosëm të krijonim vetë një sistem skedarësh të shpërndarë.
Dy vjet më vonë, disa zhvillues (të cilët kombinuan punën në vAIR me punën në sistemin klasik të ruajtjes së Motorit) arritën një rezultat të caktuar.
Deri në vitin 2018, ne kishim shkruar një sistem të thjeshtë skedarësh dhe e plotësuam atë me pajisjet e nevojshme. Sistemi kombinoi disqe fizike (lokale) nga serverë të ndryshëm në një pishinë të sheshtë nëpërmjet një ndërlidhjeje të brendshme dhe "i prerë" ato në blloqe virtuale, më pas u krijuan pajisje të bllokuara me shkallë të ndryshme të tolerancës së gabimeve nga blloqet virtuale, mbi të cilat u krijuan ato virtuale. dhe ekzekutuar duke përdorur makinat e hipervizorit KVM.
Ne nuk u mërzitëm shumë me emrin e sistemit të skedarëve dhe shkurtimisht e quajtëm atë ARDFS (mendoni se çfarë përfaqëson))
Ky prototip dukej mirë (jo vizualisht, natyrisht, nuk kishte ende një dizajn vizual) dhe tregoi rezultate të mira për sa i përket performancës dhe shkallëzimit. Pas rezultatit të parë real, ne e vumë në lëvizje këtë projekt, duke organizuar një mjedis zhvillimi të plotë dhe një ekip të veçantë që merrej vetëm me vAIR.
Vetëm në atë kohë, arkitektura e përgjithshme e zgjidhjes ishte pjekur, e cila ende nuk ka pësuar ndryshime të mëdha.
Zhytja në sistemin e skedarëve ARDFS
ARDFS është themeli i vAIR, i cili siguron ruajtjen e të dhënave të shpërndara dhe tolerante ndaj gabimeve në të gjithë grupin. Një nga veçoritë (por jo të vetmet) dalluese të ARDFS është se ai nuk përdor asnjë server shtesë të dedikuar për metadata dhe menaxhim. Kjo fillimisht u konceptua për të thjeshtuar konfigurimin e zgjidhjes dhe për besueshmërinë e saj.
Struktura e ruajtjes
Brenda të gjitha nyjeve të grupit, ARDFS organizon një grup logjik nga e gjithë hapësira e disponueshme e diskut. Është e rëndësishme të kuptohet se një grup nuk është ende hapësirë e të dhënave apo e formatuar, por thjesht markup, d.m.th. Çdo nyje me vAIR të instaluar, kur shtohet në grup, shtohet automatikisht në grupin e përbashkët ARDFS dhe burimet e diskut ndahen automatikisht në të gjithë grupimin (dhe të disponueshme për ruajtjen e të dhënave në të ardhmen). Kjo qasje ju lejon të shtoni dhe hiqni nyjet në fluturim pa ndonjë ndikim serioz në sistemin tashmë në funksion. Ato. sistemi është shumë i lehtë për t'u shkallëzuar "në tulla", duke shtuar ose hequr nyjet në grup nëse është e nevojshme.
Disqet virtuale (objektet e ruajtjes për makinat virtuale) shtohen në krye të grupit ARDFS, të cilat janë ndërtuar nga blloqe virtuale me madhësi 4 megabajt. Disqet virtuale ruajnë drejtpërdrejt të dhënat. Skema e tolerancës së gabimeve vendoset gjithashtu në nivelin e diskut virtual.
Siç mund ta keni marrë me mend tashmë, për tolerancën e gabimeve të nënsistemit të diskut, ne nuk përdorim konceptin RAID (Redundant array of pavarur Disks), por përdorim RAIN (Redundant array of pavarura Nodes). Ato. Toleranca ndaj gabimeve matet, automatizohet dhe menaxhohet bazuar në nyjet, jo në disqe. Disqet, natyrisht, janë gjithashtu një objekt ruajtjeje, ata, si çdo gjë tjetër, monitorohen, ju mund të kryeni të gjitha operacionet standarde me ta, duke përfshirë montimin e një RAID të harduerit lokal, por grupi funksionon posaçërisht në nyje.
Në një situatë ku vërtet dëshironi RAID (për shembull, një skenar që mbështet dështime të shumta në grupe të vogla), asgjë nuk ju pengon të përdorni kontrollorët lokalë RAID dhe të ndërtoni hapësirë të zgjatur dhe një arkitekturë RAIN në krye. Ky skenar është mjaft i drejtpërdrejtë dhe mbështetet nga ne, kështu që ne do të flasim për të në një artikull rreth skenarëve tipikë për përdorimin e vAIR.
Skemat e tolerancës së gabimeve të ruajtjes
Mund të ketë dy skema të tolerancës së gabimeve për disqet virtuale në vAIR:
1) Faktori i përsëritjes ose thjesht përsëritja - kjo metodë e tolerancës së gabimeve është aq e thjeshtë sa një shkop dhe një litar. Replikimi sinkron kryhet ndërmjet nyjeve me një faktor 2 (2 kopje për grup) ose 3 (përkatësisht 3 kopje). RF-2 lejon që një disk virtual të përballojë dështimin e një nyje në grup, por "ha" gjysmën e vëllimit të dobishëm, dhe RF-3 do të përballojë dështimin e 2 nyjeve në grup, por rezervon 2/3 e vëllim i dobishëm për nevojat e tij. Kjo skemë është shumë e ngjashme me RAID-1, domethënë, një disk virtual i konfiguruar në RF-2 është rezistent ndaj dështimit të ndonjë nyjeje në grup. Në këtë rast, gjithçka do të jetë në rregull me të dhënat dhe as hyrja/dalja nuk do të ndalet. Kur nyja e rënë kthehet në shërbim, do të fillojë rikuperimi/sinkronizimi automatik i të dhënave.
Më poshtë janë shembuj të shpërndarjes së të dhënave RF-2 dhe RF-3 në gjendje normale dhe në një situatë dështimi.
Ne kemi një makinë virtuale me një kapacitet prej 8 MB të dhëna unike (të dobishme), e cila funksionon në 4 nyje vAIR. Është e qartë se në realitet nuk ka gjasa që të ketë një vëllim kaq të vogël, por për një skemë që pasqyron logjikën e funksionimit të ARDFS, ky shembull është më i kuptueshëm. AB janë blloqe virtuale 4MB që përmbajnë të dhëna unike të makinës virtuale. RF-2 krijon dy kopje të këtyre blloqeve A1+A2 dhe B1+B2, respektivisht. Këto blloqe janë "shtruar" nëpër nyje, duke shmangur kryqëzimin e të njëjtave të dhëna në të njëjtën nyje, domethënë, kopja A1 nuk do të vendoset në të njëjtën nyje si kopja A2. E njëjta gjë me B1 dhe B2.
Nëse një nga nyjet dështon (për shembull, nyja nr. 3, e cila përmban një kopje të B1), kjo kopje aktivizohet automatikisht në nyjen ku nuk ka kopje të kopjes së saj (d.m.th., një kopje e B2).
Kështu, disku virtual (dhe VM, në përputhje me rrethanat) mund t'i mbijetojë lehtësisht dështimit të një nyje në skemën RF-2.
Skema e riprodhimit, ndonëse e thjeshtë dhe e besueshme, vuan nga i njëjti problem si RAID1 - hapësira e pamjaftueshme e përdorshme.
2) Kodimi i fshirjes ose kodimi i fshirjes (i njohur gjithashtu si "kodim i tepërt", "kodim i fshirjes" ose "kod i tepricës") ekziston për të zgjidhur problemin e mësipërm. EC është një skemë e tepricës që ofron disponueshmëri të lartë të të dhënave me hapësirë më të ulët në disk në krahasim me replikimin. Parimi i funksionimit të këtij mekanizmi është i ngjashëm me RAID 5, 6, 6P.
Gjatë kodimit, procesi EC ndan një bllok virtual (4MB si parazgjedhje) në disa "copa të dhënash" më të vogla në varësi të skemës EC (për shembull, një skemë 2+1 ndan çdo bllok 4MB në 2 copa 2MB). Më pas, ky proces gjeneron "copëza të barazisë" për "copëzat e të dhënave" që nuk janë më të mëdha se një nga pjesët e ndara më parë. Gjatë dekodimit, EC gjeneron pjesët që mungojnë duke lexuar të dhënat "të mbijetuara" në të gjithë grupimin.
Për shembull, një disk virtual me një skemë 2 + 1 EC, i zbatuar në 4 nyje grupimi, do të përballojë lehtësisht dështimin e një nyje në grup në të njëjtën mënyrë si RF-2. Në këtë rast, kostot e përgjithshme do të jenë më të ulëta, në veçanti, koeficienti i kapacitetit të dobishëm për RF-2 është 2, dhe për EC 2+1 do të jetë 1,5.
Për ta përshkruar më thjesht, thelbi është që blloku virtual ndahet në 2-8 (pse nga 2 në 8, shih më poshtë) "copë" dhe për këto pjesë llogariten "copë" barazie të një vëllimi të ngjashëm.
Si rezultat, të dhënat dhe barazia shpërndahen në mënyrë të barabartë në të gjitha nyjet e grupit. Në të njëjtën kohë, si me replikimin, ARDFS shpërndan automatikisht të dhënat nëpër nyje në mënyrë të tillë që të parandalojë të dhënat identike (kopjet e të dhënave dhe pariteti i tyre) të ruhen në të njëjtën nyje, në mënyrë që të eliminojë mundësinë e humbjes së të dhënave për shkak për faktin se të dhënat dhe barazia e tyre do të përfundojnë papritmas në një nyje ruajtëse që dështon.
Më poshtë është një shembull, me të njëjtën makinë virtuale 8 MB dhe 4 nyje, por me një skemë EC 2+1.
Blloqet A dhe B ndahen në dy pjesë me nga 2 MB secila (dy sepse 2+1), domethënë A1+A2 dhe B1+B2. Ndryshe nga një kopje, A1 nuk është një kopje e A2, është një bllok virtual A, i ndarë në dy pjesë, njësoj me bllokun B. Në total, marrim dy grupe prej 4 MB, secila prej të cilave përmban dy pjesë dy MB. Më tej, për secilën prej këtyre grupeve, barazia llogaritet me një vëllim jo më shumë se një copë (d.m.th. 2 MB), marrim një shtesë + 2 pjesë të barazisë (AP dhe BP). Në total kemi të dhëna 4×2 + barazi 2×2.
Më pas, pjesët "shtrohen" midis nyjeve në mënyrë që të dhënat të mos kryqëzohen me barazinë e tyre. Ato. A1 dhe A2 nuk do të jenë në të njëjtën nyje si AP.
Në rast të dështimit të një nyje (për shembull, edhe të tretës), blloku i rënë B1 do të rikthehet automatikisht nga barazia BP, e cila ruhet në nyjen nr. 2 dhe do të aktivizohet në nyjen ku ka pa barazi B, d.m.th. pjesë e BP. Në këtë shembull, kjo është nyja nr. 1
Jam i sigurt që lexuesi ka një pyetje:
"Gjithçka që përshkruani është zbatuar prej kohësh si nga konkurrentët ashtu edhe në zgjidhjet me burim të hapur, cili është ndryshimi midis zbatimit tuaj të EC në ARDFS?"
Dhe pastaj do të ketë veçori interesante të ARDFS.
Fshirja e kodimit me fokus në fleksibilitet
Fillimisht, ne siguruam një skemë mjaft fleksibël EC X+Y, ku X është e barabartë me një numër nga 2 në 8, dhe Y është i barabartë me një numër nga 1 në 8, por gjithmonë më pak se ose e barabartë me X. Kjo skemë ofrohet për fleksibilitet. Rritja e numrit të pjesëve të të dhënave (X) në të cilat ndahet blloku virtual lejon uljen e kostove të përgjithshme, domethënë rritjen e hapësirës së përdorshme.
Rritja e numrit të pjesëve të barazisë (Y) rrit besueshmërinë e diskut virtual. Sa më e madhe të jetë vlera Y, aq më shumë nyje në grup mund të dështojnë. Natyrisht, rritja e vëllimit të barazisë zvogëlon sasinë e kapacitetit të përdorshëm, por ky është një çmim që duhet paguar për besueshmërinë.
Varësia e performancës nga qarqet EC është pothuajse e drejtpërdrejtë: sa më shumë "copë", aq më e ulët është performanca; këtu, natyrisht, nevojitet një pamje e ekuilibruar.
Kjo qasje i lejon administratorët të konfigurojnë hapësirën ruajtëse të zgjatur me fleksibilitet maksimal. Brenda grupit ARDFS, mund të përdorni çdo skemë të tolerancës së gabimeve dhe kombinimet e tyre, gjë që, sipas mendimit tonë, është gjithashtu shumë e dobishme.
Më poshtë është një tabelë që krahason disa (jo të gjitha të mundshme) skema RF dhe EC.
Tabela tregon se edhe kombinimi më "i frikshëm" EC 8+7, i cili lejon humbjen e deri në 7 nyjeve në një grup në të njëjtën kohë, "ha" më pak hapësirë të përdorshme (1,875 kundrejt 2) sesa përsëritja standarde dhe mbron 7 herë më mirë. , gjë që e bën këtë mekanizëm mbrojtës, megjithëse më kompleks, shumë më tërheqës në situatat kur është e nevojshme të sigurohet besueshmëria maksimale në kushtet e hapësirës së kufizuar të diskut. Në të njëjtën kohë, duhet të kuptoni se çdo "plus" në X ose Y do të jetë një kosto shtesë e performancës, kështu që në trekëndëshin midis besueshmërisë, kursimeve dhe performancës duhet të zgjidhni me shumë kujdes. Për këtë arsye, ne do t'i kushtojmë një artikull të veçantë përcaktimit të madhësisë së kodimit të fshirjes.
Besueshmëria dhe autonomia e sistemit të skedarëve
ARDFS funksionon në nivel lokal në të gjitha nyjet e grupit dhe i sinkronizon ato duke përdorur mjetet e veta përmes ndërfaqeve të dedikuara Ethernet. Pika e rëndësishme është se ARDFS sinkronizon në mënyrë të pavarur jo vetëm të dhënat, por edhe meta të dhënat që lidhen me ruajtjen. Gjatë punës në ARDFS, ne studiuam njëkohësisht një numër zgjidhjesh ekzistuese dhe zbuluam se shumë sinkronizojnë meta të sistemit të skedarëve duke përdorur një DBMS të shpërndarë të jashtëm, të cilin ne e përdorim gjithashtu për sinkronizim, por vetëm konfigurime, jo meta të dhëna FS (për këtë dhe nënsisteme të tjera të lidhura në artikullin vijues).
Sinkronizimi i meta të dhënave FS duke përdorur një DBMS të jashtëm është, sigurisht, një zgjidhje funksionale, por atëherë qëndrueshmëria e të dhënave të ruajtura në ARDFS do të varej nga DBMS e jashtme dhe sjellja e saj (dhe, thënë sinqerisht, është një zonjë kapriçioze), e cila në mendimi ynë është i keq. Pse? Nëse të dhënat meta të FS dëmtohen, vetë të dhënat e FS mund të thuhen gjithashtu "lamtumirë", kështu që vendosëm të marrim një rrugë më komplekse por të besueshme.
Ne bëmë vetë nënsistemin e sinkronizimit të meta të dhënave për ARDFS dhe ai jeton plotësisht i pavarur nga nënsistemet ngjitur. Ato. asnjë nënsistem tjetër nuk mund të korruptojë të dhënat ARDFS. Sipas mendimit tonë, kjo është mënyra më e besueshme dhe e saktë, por koha do të tregojë nëse kjo është në të vërtetë kështu. Për më tepër, kjo qasje ka një avantazh shtesë. ARDFS mund të përdoret në mënyrë të pavarur nga vAIR, po aq sa magazinimi i zgjatur, të cilin me siguri do ta përdorim në produktet e ardhshme.
Si rezultat, duke zhvilluar ARDFS, ne morëm një sistem skedari fleksibël dhe të besueshëm që ju jep një zgjedhje ku mund të kurseni kapacitet ose të hiqni dorë nga gjithçka për performancën, ose të bëni ruajtje jashtëzakonisht të besueshme me një kosto të arsyeshme, por duke reduktuar kërkesat e performancës.
Së bashku me një politikë të thjeshtë licencimi dhe një model fleksibël ofrimi (duke parë përpara, vAIR licencohet nga nyja dhe shpërndahet ose si softuer ose si një paketë softuerike), kjo ju lejon të përshtatni me shumë saktësi zgjidhjen për një shumëllojshmëri të gjerë kërkesash të klientëve dhe atëherë me lehtësi ruajeni këtë ekuilibër.
Kush ka nevojë për këtë mrekulli?
Nga njëra anë, mund të themi se tashmë ka lojtarë në treg që kanë zgjidhje serioze në fushën e hiperkonvergjencës dhe pikërisht këtu po shkojmë. Duket se kjo deklaratë është e vërtetë, POR...
Nga ana tjetër, kur dalim në fusha dhe komunikojmë me klientët, ne dhe partnerët tanë shohim që nuk është aspak kështu. Ka shumë detyra për hiperkonvergjencë, në disa vende njerëzit thjesht nuk e dinin që zgjidhje të tilla ekzistonin, në të tjera dukej e shtrenjtë, në të tjera kishte teste të pasuksesshme të zgjidhjeve alternative, dhe në të tjera ata ndalojnë fare blerjen për shkak të sanksioneve. Në përgjithësi, fusha doli të ishte e paploruar, kështu që shkuam të ngrinim tokë të virgjër))).
Kur sistemi i ruajtjes është më i mirë se GCS?
Ndërsa punojmë me tregun, shpesh na pyesin se kur është më mirë të përdorim një skemë klasike me sisteme ruajtjeje dhe kur të përdorim hiperkonvergjent? Shumë kompani që prodhojnë GCS (veçanërisht ato që nuk kanë sisteme ruajtjeje në portofolin e tyre) thonë: "Sistemet e ruajtjes po bëhen të vjetruara, vetëm hiperkonvergjente!" Kjo është një deklaratë e guximshme, por nuk pasqyron plotësisht realitetin.
Në të vërtetë, tregu i magazinimit po shkon vërtet drejt hiperkonvergjencës dhe zgjidhjeve të ngjashme, por ka gjithmonë një "por".
Së pari, qendrat e të dhënave dhe infrastrukturat e IT të ndërtuara sipas skemës klasike me sisteme ruajtjeje nuk mund të rindërtohen lehtësisht, ndaj modernizimi dhe kompletimi i këtyre infrastrukturave është ende një trashëgimi për 5-7 vjet.
Së dyti, infrastruktura që po ndërtohet aktualisht në pjesën më të madhe (nënkupton Federatën Ruse) është ndërtuar sipas skemës klasike duke përdorur sistemet e ruajtjes, dhe jo sepse njerëzit nuk dinë për hiperkonvergjencën, por sepse tregu i hiperkonvergjencës është i ri, zgjidhjet dhe standardet nuk janë vendosur ende, njerëzit e IT nuk janë ende të trajnuar, ata kanë pak përvojë, por ata duhet të ndërtojnë qendra të dhënash këtu dhe tani. Dhe kjo prirje do të zgjasë për 3-5 vjet të tjera (dhe më pas një trashëgimi tjetër, shih pikën 1).
Së treti, ka një kufizim thjesht teknik në vonesat e vogla shtesë prej 2 milisekonda për shkrim (duke përjashtuar cache-në lokale, natyrisht), të cilat janë kostoja e ruajtjes së shpërndarë.
Epo, le të mos harrojmë përdorimin e serverëve të mëdhenj fizikë që duan shkallëzimin vertikal të nënsistemit të diskut.
Ka shumë detyra të nevojshme dhe të njohura ku sistemet e ruajtjes sillen më mirë se GCS. Këtu, natyrisht, ata prodhues që nuk kanë sisteme ruajtjeje në portofolin e produkteve të tyre nuk do të pajtohen me ne, por ne jemi të gatshëm të argumentojmë në mënyrë të arsyeshme. Sigurisht, ne, si zhvillues të të dy produkteve, patjetër do të krahasojmë sistemet e ruajtjes dhe GCS në një nga botimet tona të ardhshme, ku do të demonstrojmë qartë se cili është më i mirë në çfarë kushtesh.
Dhe ku do të funksionojnë më mirë zgjidhjet e hiperkonvergjuara sesa sistemet e ruajtjes?
Bazuar në pikat e mësipërme, mund të nxirren tre përfundime të dukshme:
- Aty ku 2 milisekonda shtesë latente për regjistrim, që ndodh vazhdimisht në çdo produkt (tani nuk po flasim për sintetikë, nanosekonda mund të shfaqen në sintetikë), janë jokritike, hiperkonvergjenti është i përshtatshëm.
- Aty ku ngarkesa nga serverë të mëdhenj fizikë mund të shndërrohet në shumë virtualë të vegjël dhe të shpërndahet midis nyjeve, hiperkonvergjenca gjithashtu do të funksionojë mirë atje.
- Aty ku shkallëzimi horizontal është një përparësi më e lartë se shkallëzimi vertikal, GCS do të funksionojë mirë edhe atje.
Cilat janë këto zgjidhje?
- Të gjitha shërbimet standarde të infrastrukturës (shërbimi i drejtorisë, posta, EDMS, serverët e skedarëve, sistemet ERP dhe BI të vogla ose të mesme, etj.). Ne e quajmë këtë "kompjuter të përgjithshëm".
- Infrastruktura e ofruesve të cloud, ku është e nevojshme të zgjerohet shpejt dhe standardizuar horizontalisht dhe të "prehet" lehtësisht një numër i madh makinash virtuale për klientët.
- Infrastruktura virtuale e desktopit (VDI), ku shumë makina virtuale të përdoruesve të vegjël funksionojnë dhe "lundrojnë" në heshtje brenda një grupi uniform.
- Rrjetet e degëve, ku çdo degë ka nevojë për një infrastrukturë standarde, tolerante ndaj gabimeve, por të lira prej 15-20 makinash virtuale.
- Çdo informatikë e shpërndarë (për shembull, shërbimet e të dhënave të mëdha). Aty ku ngarkesa nuk shkon "në thellësi", por "në gjerësi".
- Mjedise testimi ku vonesa të vogla shtesë janë të pranueshme, por ka kufizime buxhetore, sepse këto janë teste.
Për momentin, pikërisht për këto detyra kemi bërë AERODISK VAIR dhe pikërisht në to po fokusohemi (me sukses deri tani). Ndoshta kjo do të ndryshojë së shpejti, sepse... bota nuk qëndron ende.
Kështu që…
Kjo plotëson pjesën e parë të një serie të madhe artikujsh; në artikullin tjetër do të flasim për arkitekturën e zgjidhjes dhe komponentët e përdorur.
Ne mirëpresim pyetje, sugjerime dhe mosmarrëveshje konstruktive.
Burimi: www.habr.com