Përshëndetje, lexues të Habrës. Me këtë artikull ne hapim një cikël që do të flasë për sistemin hibrid të zhvilluar nga ne, AERODISK vAIR. Fillimisht dëshironim që me artikullin tonë të parë të flisnim gjithçka për gjithçka, por sistemi është mjaft kompleks, prandaj do ta hamë elefantin në pjesë.
Të fillojmë tregimin me historinë e krijimit të sistemit, do të thellohemi në sistemin e skedarëve ARDFS, i cili është baza e vAIR, si dhe do të bisedojmë pak rreth pozicionimit të këtij zgjidhjeje në tregun rus.
Në artikujt e ardhshëm do të flasim më në detaje për komponentët e ndryshëm arkitekturorë (kluster, hipervizor, balancues ngarkese, sistem monitorimi etj.), procesin e konfigurimit, do të ngremë çështjet e licencimit, do të shfaqim testet e crash-it dhe, sigurisht, do të shkruajmë për testimin e ngarkesës dhe sizing-un. Po ashtu, do t'i dedikojmë një artikull veçanërisht versionit community të vAIR.
AERODISK është si një histori e ruajtjes së të dhënave? Apo pse filluam ne në të vërtetë të merremi me hibridizimin?
Fillimisht ideja për të krijuar sistemin tonë hibrid na është ardhur dikur rreth vitit 2010. Atëherë nuk kishte as AERODISK, as zgjidhje të ngjashme (sisteme komerciale hibridizimi) në treg. Detyra jonë ishte si më poshtë: nga një grup serverësh me disqe lokale, të lidhur përmes një interkonnektiviteti me protokollin Ethernet, të krijonim një depo të shpërndarë dhe po aty të ekzekutonim makinat virtuale dhe rrjetin programor. E gjithë kjo nevojitej të realizohej pa një sistem ruajtjeje (pasi nuk kishim fonde për një sistem të tillë dhe as nuk e kishim shpikur sistemin tonë në atë kohë).
Provoëm shumë zgjidhje open source dhe megjithatë arritëm ta zgjidhnim këtë detyrë, por zgjidhja ishte shumë komplekse dhe e vështirë për t'u përsëritur. Për më tepër, kjo zgjidhje ishte në një lloj kategorie «Funksionon? Mos e prek!». Prandaj, pasi e zgjidhëm atë detyrë, nuk vendosëm të zhvillonim më tej idenë e kthimit të rezultatit të punës sonë në një produkt të plotë.
Pas asaj ngjarjeje, ne u larguam nga kjo ide, por ndjenja e asaj detyre vazhdoi të na përcjellë, ndërsa dobinë nga një zgjidhje e tillë e kishte më se të dukshme. Në vazhdim, produktet HCI të lansuara nga kompanitë e huaja vetëm sa e konfirmuan këtë ndjenjë.
Prandaj, në mesin e vitit 2016, ne u kthyem në këtë projekt si pjesë e krijimit të një produkti të plotë. Në atë kohë, ne nuk kishim asnjë marrëdhënie me investitorët, prandaj u detyruam të blinim stendën e zhvillimit me paratë tona të vogla. Duke kërkuar në Avito për serverë dhe switch-e të përdorur, filluam punën.
Detyra kryesore fillestare ishte krijimi i një sistemi të vetin të skedarëve, pavarësisht se sa i thjeshtë, që do të ishte në gjendje të shpërndante automatikisht dhe në mënyrë të barabartë të dhënat në formën e blloqeve virtuale në një numër n të nyjeve të klusterit, të cilat ishin të lidhura me njëra-tjetrën përmes Ethernet-it. Në të njëjtën kohë, FS duhej të shkallëzonte mirë dhe lehtësisht dhe të ishte e pavarur nga sistemet e afërta, dmth. të ishte e shkëputur nga vAIR si një "thjesht ruajtje".
Koncepti i parë i vAIR
Ne qëllimisht refuzuam përdorimin e zgjidhjeve gati të hapura open source për organizimin e një depozitimi të shpërndarë (ceph, gluster, lustre dhe të ngjashme) në favor të zhvillimit tonë, pasi tashmë kishim përvojë të madhe projektimi me to. Sigurisht, këto zgjidhje janë të shkëlqyera vetë, dhe para se të fillonim punën me Aerodisk, kishim realizuar disa projekte integruese me to. Por një gjë është të realizosh një detyrë specifike për një klient, të trajnotosh stafin dhe, ndoshta, të blesh mbështetje nga një ofrues i madh, dhe krejt ndryshe është të krijosh një produkt të lehtë për ta riprodhuar, që do të përdoret për detyra të ndryshme, që për to, si ofrues, ndoshta nuk do të dimë as vetë. Për qëllimin e dytë, produktet ekzistuese open source nuk na përshtateshin, prandaj vendosëm ta zhvillonim sistemin e shpërndarë të skedarëve vetë.
Pas dy vitesh, forca e disa zhvilluesve (të cilët kombinonin punën mbi vAIR me punën mbi klasiken SHD Engine) arritën një rezultat të caktuar.
Në vitin 2018, ne shkruam një sistem të thjeshtë skedarësh dhe e plotësuam atë me lidhjet e nevojshme. Sistemi bashkonte disqet fizike (lokale) nga serverë të ndryshëm në një reservoir të sheshtë dhe i "priste" ato në blloqe virtuale, më pas nga blloqet virtuale krijoheshin pajisje bllokues me një nivel të caktuar të qëndrueshmërisë ndaj dështimeve, mbi të cilat, me ndihmën e hipervizorit KVM, krijoheshin dhe ekzekutoheshin makinat virtuale.
Ne kemi vendosur ta quajmë sistemin e skedarëve ARDFS (kuptoni vetë se çfarë do të thotë))
Ky prototip dukej mirë (sigurisht, jo vizualisht, sepse atëherë nuk kishte as një dizajn vizual) dhe tregoi rezultate të mira në performancë dhe shkallëzueshmëri. Pas rezultatit të parë real, e vazhduam këtë projekt, duke organizuar një mjedis të plotë zhvillimi dhe një ekip të veçantë që merrej vetëm me vAIR.
Ajo kohë e bëri të qartë arkitekturën e përgjithshme të zgjidhjes, e cila deri tani nuk ka pësuar ndryshime të rëndësishme.
Le të thellojmë në sistemin e skedarëve ARDFS
ARDFS është baza e vAIR, e cila siguron ruajtjen e të dhënave të shpërndara dhe të besueshme të gjithë klasterit. Një nga (por jo e vetmja) veçori dalluese e ARDFS është se ajo nuk përdor asnjë menaxhim të jashtëm. serverësh të dedikuar I gjithë ky koncept është menduar fillimisht për të thjeshtuar konfigurimin e zgjidhjes dhe për besueshmërinë e saj.
Struktura e ruajtjes
NĂ« tĂ« gjitha nodet e klasterit, ARDFS organizon njĂ« rezervuar logjik nga e gjithĂ« hapĂ«sira e disponueshme e shtesave. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« kuptoni se rezervuari nuk janĂ« ende tĂ« dhĂ«na dhe as hapĂ«sirĂ« e formatizuar, por thjesht njĂ« ndarje, dmth. çdo nodĂ« me vAIR tĂ« instaluar kur shtohet nĂ« klaster automatikisht bashkohet nĂ« rezervuarin e pĂ«rbashkĂ«t ARDFS dhe burimet diskore bĂ«hen automatikisht tĂ« zakonshme pĂ«r tĂ« gjithĂ« klasterin (dhe tĂ« disponueshme pĂ«r ruajtjen e ardhshme tĂ« tĂ« dhĂ«nave). Ky qasje lejon qĂ« nodet tĂ« shtohen dhe hiqen nĂ« flakĂ« pa ndonjĂ« ndikim tĂ« rĂ«ndĂ«sishĂ«m nĂ« sistemin qĂ« po punon. Pra, sistemi Ă«shtĂ« shumĂ« i lehtĂ« pĂ«r t'u shkallĂ«zuar me 'blloqe', duke shtuar ose hequr nodet nga klasteri sipas nevojĂ«s.
Përmbi rezervuarin ARDFS shtohen disqet virtuale (objekte ruajtjeje për virtualët), të cilat ndërtohen nga blloqe virtuale me madhësi 4 megabajt. Të dhënat ruhen drejtpërdrejt në disqet virtuale. Në nivelin e disqeve virtuale gjithashtu përcaktohet një skemë besueshmërie.
Si ndoshta mund të keni kuptuar, për disponueshmërinë e sistemit të diskut nuk përdorim konceptin RAID (Grupi i tepërt i Disqeve të Pavarura), por përdorim RAIN (Grupi i tepërt i Nodëve të Pavarur). Pra, disponueshmëria matet, automatizohet dhe menaxhohet në bazë të nodëve, jo të disqeve. Disqet, natyrisht, janë gjithashtu objekte ruajtjeje, ato, ashtu si gjithçka tjetër, monitorohen dhe mund të kryejnë të gjitha operacionet standarde, përfshirë ndërtimin e një RAID lokal, por klubi operon pikërisht me nodët.
Në situata kur shumë dëshirohet RAID (p.sh., skenari që mbështet dështime të shumta në klasterët e vegjël), asgjë nuk e ndalon përdorimin e kontrollorëve të RAID lokalë, dhe mbi ta të krijohet një ruajtje e zgjatur dhe një arkitekturë RAIN. Ky skenar është plotësisht i zbatueshëm dhe mbështetet nga ne, prandaj do ta diskutojmë në artikullin tonë për skenarët tipik të përdorimit të vAIR.
Skemat e disponueshmërisë së ruajtjes
Mund të ketë dy skema disponueshmërie për disqet virtuale në vAIR:
1) Faktori i replikimit ose thjesht replikimi â kjo metodĂ« disponueshmĂ«rie Ă«shtĂ« e thjeshtĂ« "si njĂ« shkop dhe litar". Kryhet replikimi sinkron midis nodĂ«ve me faktor 2 (2 kopje pĂ«r klaster) ose 3 (3 kopje, pĂ«rkatĂ«sisht). RF-2 i lejon disqet virtuale tĂ« pĂ«rballojnĂ« dĂ«shtimin e njĂ« nodi nĂ« klaster, por "ha" gjysmĂ«n e volumit tĂ« dobishĂ«m, ndĂ«rsa RF-3 do tĂ« pĂ«rballojĂ« dĂ«shtimin e 2 nodĂ«ve nĂ« klaster, por do t'i rezervojĂ« 2/3 tĂ« volumit tĂ« 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Ă« i qĂ«ndrueshĂ«m ndaj dĂ«shtimit tĂ« cilitdo nod tĂ« vetĂ«m tĂ« klasterit. NĂ« kĂ«tĂ« rast, tĂ« dhĂ«nat do tĂ« jenĂ« nĂ« rregull dhe madje I/O nuk do tĂ« ndalet. Kur nodi i rĂ«nĂ« tĂ« kthehet nĂ« punĂ«, 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ë modalitetin normal dhe në situatat e dështimeve.
Ne kemi njĂ« makinĂ« virtuale me 8MB tĂ« dhĂ«nash unike (tĂ« dobishme), e cila punon nĂ« 4 nodet vAIR. ĂshtĂ« e qartĂ« se nĂ« realitet njĂ« volum kaq i vogĂ«l nuk do tĂ« jetĂ« i mundur, por pĂ«r diagramĂ«n qĂ« pasqyron logjikĂ«n e punĂ«s sĂ« ARDFS, ky shembull Ă«shtĂ« mĂ« i qartĂ«. AB janĂ« blloqe virtuale prej 4MB qĂ« pĂ«rmbajnĂ« tĂ« dhĂ«na unike tĂ« makinĂ«s virtuale. NĂ« RF-2 krijohen dy kopje tĂ« kĂ«tyre blloqeve A1 + A2 dhe B1 + B2, pĂ«rkatĂ«sisht. KĂ«to blloqe âshpĂ«rndahenâ nĂ« nodet, duke shmangur mbivendosjen e tĂ« njĂ«jtave tĂ« dhĂ«na nĂ« njĂ« nodĂ«, domethĂ«nĂ« kopja A1 nuk do tĂ« jetĂ« nĂ« njĂ« nodĂ« me kopjen A2. Me B1 dhe B2 Ă«shtĂ« e ngjashme.
Në rast se njëra nga nodet ndalon (p.sh., nodi nr. 3, ku ndodhet kopja B1), kjo kopje aktivizohet automatikisht në nodin ku nuk ka kopje të kopjes së saj (domethënë kopjes B2).
Kështu, disku virtual (dhe VM, përkatësisht) do t'i mbijetojë lehtë ndalimit të një nodi në skemën RF-2.
Skema me replikim, megjithĂ«se e thjeshtĂ« dhe e besueshme, vuan nga tĂ« njĂ«jtin problem si RAID1 â hapĂ«sirĂ« e vogĂ«l tĂ« dobishme.
2) Kodimi i fshirjes ose kodimi i fshirjes (i njohur gjithashtu si «kodim i tepricës» ose «kod i tepricës») ekziston për të zgjidhur problemin e mësipërm. EC është një skemë teprice që garanton një akses të lartë në të dhëna me më pak shpenzime në hapësirën e diskut krahasuar me replikimin. Parimi i funksionimit të këtij mekanizmi është i ngjashëm me RAID 5, 6, 6P.
NĂ« kodimin EC, procesi e ndan bllokun virtual (pĂ«r default 4MB) nĂ« disa âcopĂ«za tĂ« dhĂ«nashâ mĂ« tĂ« vogla, varĂ«sisht nga skema EC (p.sh., skema 2 + 1 e ndan çdo bllok 4 MB nĂ« 2 copa prej 2MB). Pas kĂ«saj, ky proces gjeneron pĂ«r âcopĂ«zat e tĂ« dhĂ«naveâ âcopĂ«za paritetiâ me madhĂ«si jo mĂ« tĂ« madhe se njĂ« nga pjesĂ«t e ndara mĂ« parĂ«. Kur dekodohet, EC gjeneron copĂ«t qĂ« mungojnĂ« duke lexuar tĂ« dhĂ«nat âe mbeturaâ nĂ« tĂ« gjithĂ« klasterin.
Për shembull, disku virtual me skemën EC 2 + 1, e realizuar në 4 nodet e klasterit, do të përballojë lehtësisht ndalimin e një nodi në klaster ashtu si RF-2. Ndërsa shpenzimet do të jenë më të ulta, në veçanti koeficienti i kapacitetit të dëgjueshëm në RF-2 është 2, ndërsa për EC 2 + 1 do të jetë 1,5.
NĂ«se pĂ«r ta pĂ«rshkruar mĂ« thjeshtĂ«, thelbi Ă«shtĂ« se blloku virtual ndahet nĂ« 2-8 (pse nga 2 deri nĂ« 8 shih mĂ« poshtĂ«) âcopĂ«zaâ, dhe pĂ«r kĂ«to copĂ«za llogariten âcopĂ«zaâ pariteti tĂ« njĂ«jtĂ« nĂ« volum.
Si në fund, të dhënat dhe pariteti shpërndahen në mënyrë uniforme në të gjitha nodet e klasterit. Po ashtu, si në rastin e replikimit, ARDFS automatikisht shpërndan të dhënat në nodet në një mënyrë që parandalon ruajtjen e të njëjtave të dhëna (kopia e të dhënave dhe pariteti i tyre) në një nod, për të eliminuar mundësinë e humbjes së të dhënave, nëse të dhënat dhe pariteti i tyre ndodhen papritur në një nod ruajtjeje që dështojnë.
Më poshtë është një shembull, me të njëjtën virtualizim në 8 MB dhe 4 nod, por tashmë me skemën EC 2+1.
Blloqet A dhe B ndahen nĂ« dy pjesĂ« secila 2 MB (nĂ« dy sepse 2+1), pra nĂ« A1+A2 dhe B1+B2. NĂ« kundĂ«rshtim me replikĂ«n, A1 nuk Ă«shtĂ« njĂ« kopje e A2, Ă«shtĂ« njĂ« bllok virtual A, i ndarĂ« nĂ« dy pjesĂ«, ashtu si edhe blloku B. NĂ« pĂ«rfundim, ne kemi dy grupe prej 4MB, nĂ« secilin prej tĂ« cilĂ«ve ndodhen dy copĂ«za dymegabajtĂ«she. MĂ« tej, pĂ«r secilin prej kĂ«tyre grupeve llogaritet pariteti me njĂ« volum mĂ« tĂ« vogĂ«l se njĂ« copĂ« (dmth. 2 MB), duke marrĂ« pĂ«rfundimisht + 2 copĂ«za pariteti (A-P dhe B-P). NĂ« pĂ«rfundim, kemi 4Ă2 tĂ« dhĂ«na + 2Ă2 paritet.
Më tej, copëzat "shpërndahen" në nodet në një mënyrë që të dhënat të mos përputhen me paritetin e tyre. Kështu, A1 dhe A2 nuk do të jenë në të njëjtën nod me A-P.
NĂ« rast tĂ« defektit tĂ« njĂ« nodi (le tĂ« themi, nodi i tretĂ«), blloku i rĂ«nĂ« B1 do tĂ« rikthehet automatikisht nga pariteti B-P, i ruajtur nĂ« nodin nr. 2, dhe do tĂ« aktivizohet nĂ« nodin ku nuk ka paritet B, dmth. copĂ«za B-P. NĂ« kĂ«tĂ« shembull â kjo Ă«shtĂ« nodi nr. 1.
Jam i sigurt që lexuesi ka një pyetje:
"Gjithçka që keni përshkruar, është realizuar prej kohësh nga konkurrentët dhe në zgjidhjet open source, cila është ndryshimi i implementimit tuaj të EC në ARDFS?"
Më pas do të paraqiten karakteristikat interesante të funksionimit të ARDFS.
Kodimi i shkatërrimit me theks në fleksibilitet
Fillimisht ne parashikuam një skemë mjaft fleksibël EC X+Y, ku X është numri nga 2 deri në 8, dhe Y është numri nga 1 deri në 8, por gjithmonë më i vogël ose i barabartë me X. Kjo skemë është parashikuar për fleksibilitet. Rritja e numrit të copëzave të të dhënave (X), në të cilat ndahet blloku virtual, lejon uljen e kostove operative, pra rritjen e hapësirës së dobishme.
Rritja e numrit të copëzave të paritetit (Y) rrit qëndrueshmërinë e diskut virtual. Sa më e madhe të jetë vlera e Y, aq më shumë nodet në klaster mund të dështojnë. Natyrisht, rritja e volumit të paritetit ul volumetrinë e kapacitetit të dobishëm, por kjo është një çmim për qëndrueshmëri.
Varësia e performancës në skemat EC është pothuajse e drejtpërdrejtë: sa më shumë "copëza", aq më e ulët është performanca, këtu, është e qartë, nevojitet një vlerësim i balancuar.
Ky qasje lejon administratorët të konfigurojnë ruajtjen e zgjatur sa më fleksibël. Brenda grupit ARDFS është e mundur të përdoren çdo skemë të qëndrueshmërisë dhe kombinime të tyre, që gjithashtu, sipas mendimit tonë, është shumë e dobishme.
Më poshtë është një tabelë krahasimi e disa (jo të gjitha të mundshme) skemave RF dhe EC.
Nga tabela tregohet se edhe kombinimi më "i avancuar" EC 8+7, i cili lejon humbjen e deri në 7 nodëve në klaster, "hap" më pak hapësirë të dobishme (1,875 ndaj 2), se sa replikimi standard, dhe mbron 7 herë më mirë, që e bën këtë mekanizëm mbrojtjeje ndonëse më të ndërlikuar, por dukshëm më tërheqës në situatat kur është e nevojshme të sigurohet një besueshmëri maksimale në kushte të mungesës së hapësirës diskore. Në të njëjtën kohë, duhet të kuptohet se çdo "plus" në X ose Y do të jetë një shpenzim shtesë në performancë, prandaj në trekëndëshin mes besueshmërisë, kursimit dhe performancës duhet të zgjidhet me shumë kujdes. Për këtë arsye, një artikull të veçantë do t'i kushtohet dimensionimit të kodimit të largët.
Besueshmëria dhe autonomitë e sistemit të skedarëve
ARDFS Đ·Đ°ĐżŃŃĐșĐ°het lokal nĂ« tĂ« gjitha nodĂ«t e klasterit dhe sinkronizon ato me mjete tĂ« veta pĂ«rmes ndĂ«rfaqeve tĂ« dedikuara Ethernet. NjĂ« aspekt i rĂ«ndĂ«sishĂ«m Ă«shtĂ« se ARDFS sinkronizon automatikisht jo vetĂ«m tĂ« dhĂ«nat, por edhe metadatĂ«n e lidhur me ruajtjen. GjatĂ« punĂ«s mbi ARDFS kemi studiuar paralelisht njĂ« sĂ«rĂ« zgjidhjesh ekzistuese dhe kemi zbuluar se shumĂ« bĂ«jnĂ« sinkronizimin e metadata-s sĂ« sistemit tĂ« skedarĂ«ve me anĂ« tĂ« njĂ« DB tĂ« shpĂ«rndara tĂ« jashtme, tĂ« cilĂ«n ne gjithashtu e pĂ«rdorim pĂ«r sinkronizimin, por vetĂ«m pĂ«r konfigurimet, e jo pĂ«r metadatat e FS (pĂ«r kĂ«tĂ« dhe pĂ«r sisteme tĂ« tjera lidhur do tĂ« flasim nĂ« artikullin tjetĂ«r).
Sinkronizimi i metadata tĂ« FS-sĂ« duke pĂ«rdorur njĂ« DB tĂ« jashtme Ă«shtĂ« njĂ« zgjidhje, natyrisht, e funksionueshme, por kĂ«shtu konsistenca e tĂ« dhĂ«nave tĂ« ruajtura nĂ« ARDFS do tĂ« varej nga DB e jashtme dhe sjellja e saj (ndĂ«rsa ajo, pĂ«r tĂ« mos thĂ«nĂ« ndryshe - Ă«shtĂ« njĂ« zonjĂ« e kaprici), gjĂ« qĂ« sipas mendimit tonĂ« Ă«shtĂ« e keqe. Pse? NĂ«se metadata e FS-sĂ« dĂ«mtohet, edhe tĂ« dhĂ«nat e vetĂ« FS-sĂ« mund tâi themi «mirupafshim», prandaj vendosĂ«m tĂ« ndjekim njĂ« rrugĂ« mĂ« tĂ« komplikuar, por mĂ« tĂ« besueshme.
Ne e zhvilluam në mënyrë të pavarur nën-sistemin e sinkronizimit të metadata për ARDFS, dhe ai jeton plotësisht i pavarur nga nën-sistemat e tjera. Kjo do të thotë, asnjë nën-sistem tjetër nuk mund të dëmtojë të dhënat e ARDFS. Sipas mendimit tonë, kjo është rruga më e besueshme dhe e duhur, nëse është kjo në të vërtetë - koha do ta tregojë. Për më tepër, me këtë qasje shfaqet një përfitim shtesë. ARDFS mund të përdoret pavarësisht nga vAIR, thjesht si një magazinë e shtrirë, gjë që me siguri do ta shfrytëzojmë në produktet tona të ardhshme.
Si rezultat, pasi zhvilluam ARDFS, morĂ«m njĂ« sistem tĂ« fileve fleksibĂ«l dhe tĂ« besueshĂ«m, qĂ« ofron njĂ« zgjedhje se ku mund tĂ« kursehen kapacitetet ose tâi jepni gjithçka performancĂ«s, ose tĂ« bĂ«ni magazinimin jashtĂ«zakonisht tĂ« besueshĂ«m pĂ«r njĂ« çmim tĂ« arsyeshĂ«m, por duke ulur kĂ«rkesat pĂ«r performancĂ«.
Bashkë me një politikë të thjeshtë licencimi dhe një model fleksibël shpërndarjeje (për të mos e humbur bazën, vAIR licencohet sipas nyjave, dhe ëshë i disponueshëm ose si software, ose si PAK) kjo lejon që të precisohet zgjidhja për kërkesa të ndryshme të klientëve dhe më tej ta mirëmbajë lehtësisht këtë balancë.
Kush i nevojitet këtij mrekullie?
Nga njëra anë, mund të thuhet se në treg tashmë ka lojtarë, të cilët kanë zgjidhje serioze në fushën e hiper-konvergjencës, dhe ku ne, në thelb, po hyjmë. Kjo duket se është një pohim i saktë, POR...
Nga ana tjetër, duke dalë "në terren" dhe duke biseduar me klientët, ne dhe partnerët tanë shohim se kjo nuk është aspak e vërtetë. Ka shumë detyra për hiper-konvergjencën, ndonjëherë njerëzit thjesht nuk dinin se këto zgjidhje ekzistonin, ndonjëherë këtë e shihnin si të shtrenjtë, në disa raste kishte teste të dështuara të zgjidhjeve alternative, dhe në disa raste ndalohen blerjet për shkak të sanksioneve. Në përgjithësi, fusha doli të ishte e paprekur, prandaj ne vendosëm të fillojmë një punë të re))).
Kur është HHD më e mirë se GKS?
GjatĂ« punĂ«s me tregun, shpesh na pyesin se kur Ă«shtĂ« mĂ« mirĂ« tĂ« pĂ«rdorim skemĂ«n klasike me SĂD dhe kur â hiperconvergent? ShumĂ« kompani â prodhues tĂ« GKS (veçanĂ«risht ata qĂ« nuk kanĂ« SĂD nĂ« portofolin e tyre) thonĂ«: "SĂD po kalon, vetĂ«m hiperconvergent!". Ky Ă«shtĂ« njĂ« pohim i guximshĂ«m, por nuk e reflekton plotĂ«sisht realitetin.
Sinqerisht, tregu i SĂD-ve po kalon nĂ« drejtim tĂ« hiperconvergentĂ«ve dhe zgjidhjeve tĂ« ngjashme, por gjithmonĂ« ka "por".
SĂ« pari, qendrat e tĂ« dhĂ«nave dhe infrastrukturat IT tĂ« ndĂ«rtuara sipas skemĂ«s klasike me SĂD nuk mund tĂ« pĂ«rshtaten aq lehtĂ«, prandaj modernizimi dhe ndĂ«rtimi i tillave Ă«shtĂ« ende njĂ« trashĂ«gimi pĂ«r 5-7 vitet e ardhshme.
SĂ« dyti, ato infrastruktura qĂ« po ndĂ«rtohen aktualisht nĂ« masĂ« (duke u referuar RF) po ndĂ«rtohen sipas skemĂ«s klasike me pĂ«rdorimin e SĂD dhe jo sepse njerĂ«zit nuk dinĂ« pĂ«r hiperconvergentĂ«t, por sepse tregu i hiperconvergentĂ«ve Ă«shtĂ« i ri, zgjidhjet dhe standardet ende nuk janĂ« formuar, specialistĂ«t IT ende nuk janĂ« trajnuar, ka pak pĂ«rvojĂ« dhe duhet tĂ« ndĂ«rtohen qendrat e tĂ« dhĂ«nave kĂ«tu dhe tani. Dhe kjo prirje do tĂ« vazhdojĂ« edhe pĂ«r 3-5 vite (dhe pastaj njĂ« trashĂ«gimi, shiko pika 1).
Së treti, ka një kufizim të pastër teknik në vonesat shtesë të vogla prej 2 milisekondash në shkruarje (pa marrë parasysh cache-in lokal, sigurisht), të cilat janë kosto për ruajtjen e ndarë.
Dhe mos harrojmë përdorimin e serverëve fizikë të mëdhenj, të cilat preferojnë skalimin vertikal të sistemit të diskut.
Ka shumĂ« detyra tĂ« nevojshme dhe popullore, ku SĂD sillet mĂ« mirĂ« se GKS. Sigurisht, prodhuesit qĂ« nuk kanĂ« SĂD nĂ« portofolin e tyre nuk do tĂ« bien dakord me ne, por ne jemi tĂ« gatshĂ«m tĂ« argumentohemi. Natyrisht, si zhvillues tĂ« tĂ« dy produkteve, nĂ« njĂ« nga publikimet e ardhshme do tĂ« bĂ«jmĂ« njĂ« krahasim tĂ« SĂD dhe GKS, ku do tĂ« demonstrojmĂ« qartĂ« se nĂ« cilat kushte performojnĂ« mĂ« mirĂ«.
NĂ« cilat zgjidhje hiperconvergente do tĂ« punojnĂ« mĂ« mirĂ« se SĂD?
Duke u bazuar në thëniet më sipër, mund të nxjerrim tri përfundime të qarta:
- Aty ku vonesat shtesë prej 2 milisekondash në shkruarje, të cilat shfaqen gjithmonë në çdo produktiv (kështu që nuk po flasim për sintetiken, sepse në sintetike mund të tregoni edhe nanosekonda), janë të pranueshme, hiperconvergent i përshtatet.
- Aty ku ngarkohet nga servera fizikë të mëdhenj mund të shndërrohet në shumë të vogla virtuale dhe të shpërndahen në node, atje gjithashtu do të pikaset siç duhet hyperconverged.
- Aty ku shkallëzimi horizontal është më prioritare se ai vertical, do të pritet gjithashtu që GKS të përshtatet në mënyrë të shkëlqyer.
ĂfarĂ« janĂ« kĂ«to zgjidhje?
- Të gjitha shërbimet standarde të infrastrukturës (shërbimi i katalogëve, posta, SED, serverët e skedarëve, sistemi ERP dhe BI të vogla ose të mesme etj.). Ne i quajmë këto "llogaritje të përbashkëta".
- Infrastruktura e ofruesve të shërbimeve në cloud, ku është e nevojshme të zgjerohet horizontalisht shpejt dhe standardizuar dhe të priten lehtësisht një numër i madh makinash virtuale për klientët.
- Infrastruktura e skripteve virtuale (VDI), ku shumë makina virtuale të vogla të përdoruesve aktivizohen dhe notojnë qetësisht brenda një klasteri uniforme.
- Rrjetet filial, ku në çdo filial është e nevojshme të arrihet një infrastrukturë standarde, me qëndrim të besueshëm, por njëkohësisht të përballueshme nga 15-20 makina virtuale.
- Ădo llogaritje e shpĂ«rndarĂ« (shĂ«rbimet big data, pĂ«r shembull). Aty ku ngarkesa shkon jo "thellĂ«", por "gjerĂ«".
- Mjedise testuese, ku janë të pranueshme vonesa të vogla, por ka kufizime buxhetore, pasi janë teste.
Në këtë moment, për këto detyra ne kemi krijuar AERODISK vAIR dhe kemi vendosur theksin tek to (deri tani me sukses). Mund të ndodhi që kjo të ndryshojë së shpejti, pasi bota nuk qëndron në vend.
PraâŠ
Kjo është pjesa e parë e një cikli të madh artikujsh, në artikullin e ardhshëm ne do të flasim për arkitekturën e zgjidhjes dhe komponentët e përdorur.
Do të jemi të lumtur për pyetje, propozime dhe debata konstruktive.
Burimi: habr.com
