Kaixo, Habr irakurle. Artikulu honekin garatu dugun AERODISK vAIR sistema hiperkonbergatuari buruz hitz egingo duen serie bat irekiko dugu. Hasieran, dena kontatu nahi genuen lehen artikuluan, baina sistema nahiko konplexua da, beraz, zatika jango dugu elefantea.
Hasi gaitezen istorioa sistemaren sorreraren historiarekin, sakon dezagun ARDFS fitxategi-sisteman, hau da, vAIR-en oinarria, eta hitz egin dezagun apur bat irtenbide honen posizionamenduari buruz Errusiako merkatuan.
Etorkizuneko artikuluetan osagai arkitektoniko ezberdinei buruz (kluster, hipervisor, karga-orekatzailea, monitorizazio-sistema, etab.), konfigurazio-prozesuari buruz, lizentzia-arazoak planteatu, hutsegite-probak bereizita erakutsiko ditugu eta, jakina, karga-probei buruz idatziko dugu. dimentsionatzea. Beste artikulu bat ere eskainiko diogu vAIR-ren komunitatearen bertsioari.
Aerodisk biltegiratze sistemei buruzko istorio bat al da? Edo zergatik hasi ginen lehenbiziko hiperkonbergentzia egiten?
Hasieran, gure hiperkonbergentzia sortzeko ideia 2010 inguruan sortu zitzaigun. Garai hartan, ez zegoen ez Aerodisk, ez antzeko soluziorik (kutxadun sistema hiperkonbergente komertzialak) merkatuan. Gure zeregina honakoa zen: disko lokaleko zerbitzari multzo batetik, Ethernet protokoloaren bidez interkonexio baten bidez elkartuta, biltegiratze hedatu bat sortu eta bertan makina birtualak eta software sare bat martxan jarri behar zen. Hori guztia biltegiratze-sistemarik gabe ezarri behar zen (biltegiratze-sistemetarako eta bere hardwarerako dirurik ez zegoelako, eta oraindik ez genuelako gure biltegiratze-sistemarik asmatu).
Kode irekiko irtenbide asko probatu genituen eta azkenean arazo hau konpondu genuen, baina konponbidea oso konplexua eta zaila zen errepikatzea. Gainera, irtenbide hau “Funtzionatzen al du? Ez ukitu! Hori dela eta, arazo hori konponduta, ez genuen gehiago garatu gure lanaren emaitza produktu oso batean bihurtzeko ideia.
Gertaera horren ostean, ideia honetatik aldendu ginen, baina oraindik ere arazo hori guztiz konpongarria zelako sentsazioa genuen, eta irtenbide horren onurak agerikoak baino nabariagoak ziren. Gerora, atzerriko enpresen HCI produktuek sentsazio hori berretsi baino ez zuten egin.
Hori dela eta, 2016aren erdialdean, zeregin horretara itzuli ginen, produktu oso bat sortzearen baitan. Garai hartan oraindik ez genuen harremanik inbertitzaileekin, beraz, garapenerako stand bat erosi behar izan genuen gure diru ez oso handirako. Erabilitako zerbitzariak eta Avito etengailuak bilduta, negozioari ekin genion.
Hasierako zeregin nagusia gure fitxategi-sistema propioa sortzea izan zen, sinplea bada ere, gure fitxategi-sistema, automatikoki eta uniformeki datuak bloke birtualen moduan banatu ditzakeen cluster-ko nodoen n-garren zenbakian, interkonexio baten bidez Ethernet bidez konektatzen direnak. Aldi berean, FSk ondo eta erraz eskalatu behar du eta aldameneko sistemetatik independentea izan behar du, hau da. vAIR-tik urrundu "biltegiratze-instalazio bat besterik ez" moduan.
Lehen vAIR kontzeptua
Biltegiratze luzatua antolatzeko prest egindako kode irekiko irtenbideak (ceph, gluster, luster eta antzekoak) erabiltzeari utzi genion nahita, gure garapenaren alde, jada proiektuetan esperientzia handia geneukan haiekin. Jakina, soluzio hauek bikainak dira, eta Aerodisk-en lan egin aurretik, haiekin integrazio proiektu bat baino gehiago inplementatu genituen. Baina gauza bat da bezero batentzako zeregin zehatz bat ezartzea, langileak prestatzea eta, agian, hornitzaile handi baten laguntza erostea, eta beste gauza bat da erraz errepikatzeko produktu bat sortzea, hainbat zereginetarako erabiliko dena. saltzaileak, baliteke geure buruari buruz ere ez dugula jakingo. Bigarren xederako, lehendik zeuden kode irekiko produktuak ez ziren egokiak guretzat, beraz, banatutako fitxategi-sistema geuk sortzea erabaki genuen.
Bi urte geroago, hainbat garatzailek (vAIR-en lana eta Engine biltegiratze sistema klasikoaren lana konbinatu zuten) emaitza jakin bat lortu zuten.
2018rako, fitxategi sistema sinple bat idatzi genuen eta beharrezko hardwarearekin osatu genuen. Sistemak zerbitzari ezberdinetako disko fisikoak (lokalak) konbinatu zituen igerileku lau batean barne-interkonexio baten bidez eta bloke birtualetan "moztu", gero bloke birtualetatik akatsen tolerantzia-maila ezberdineko gailuak blokeatu ziren, eta horietan birtualak sortu ziren. eta KVM hipervisor autoak erabiliz exekutatu.
Ez genuen gehiegi arduratu fitxategi-sistemaren izenarekin eta laburki ARDFS deitu genion (asmatu zer esan nahi duen))
Prototipo honek itxura ona zuen (ez bisualki, noski, oraindik ez zegoen diseinu bisualik) eta emaitza onak erakutsi zituen errendimendu eta eskalatze aldetik. Lehenengo emaitza errealaren ondoren, proiektu hau martxan jarri genuen, garapen-ingurune oso bat eta vAIR-ekin soilik jorratzen zuen talde bereizi bat antolatuz.
Ordurako, konponbidearen arkitektura orokorra heldua zen, oraindik aldaketa handirik izan ez duena.
ARDFS fitxategi-sisteman murgiltzea
ARDFS vAIR-en oinarria da, akatsen aurrean datu biltegiratze banatua eskaintzen duena kluster osoan. ARDFSren ezaugarri bereizgarrietako bat (baina ez bakarra) da ez duela metadatuak eta kudeaketarako zerbitzari dedikatu gehigarririk erabiltzen. Hasiera batean irtenbidearen konfigurazioa errazteko eta fidagarritasunerako pentsatu zen.
Biltegiratze-egitura
Klusterraren nodo guztien barruan, ARDFS-k biltegi logiko bat antolatzen du eskuragarri dagoen disko-espazio guztitik. Garrantzitsua da ulertzea igerileku bat ez dela oraindik datu edo formateatutako espazioa, markaketa besterik ez dela, hau da. vAIR instalatuta duten nodo guztiak, klusterera gehitzen direnean, automatikoki gehitzen dira partekatutako ARDFS igerilekuan eta disko-baliabideak automatikoki partekatzen dira kluster osoan (eta etorkizuneko datuak biltegiratzeko eskuragarri). Planteamendu honek nodoak berehala gehitzeko eta kentzeko aukera ematen du jada martxan dagoen sisteman eragin larririk gabe. Horiek. sistema oso erraza da "adreiluetan" eskalatzea, beharrezkoa izanez gero klusterrean nodoak gehituz edo kenduz.
Disko birtualak (makina birtualen biltegiratze-objektuak) ARDFS igerilekuaren gainean gehitzen dira, 4 megabyteko tamainako bloke birtualetatik eraikitakoak. Disko birtualek zuzenean gordetzen dituzte datuak. Akatsen tolerantzia-eskema disko birtualean ere ezartzen da.
Dagoeneko asmatuko zenuten bezala, disko azpisistemaren akatsen tolerantziarako, ez dugu RAID kontzeptua erabiltzen (Redundant array of independent Disks), baizik eta RAIN (Redundant array of independent Nodes). Horiek. Akatsen tolerantzia neurtu, automatizatu eta kudeatzen da nodoetan oinarrituta, ez diskoetan. Diskoak, noski, biltegiratze-objektu bat ere badira, gainontzeko guztia bezala kontrolatzen dira, horiekin eragiketa estandar guztiak egin ditzakezu, tokiko hardware-RAID bat muntatzea barne, baina klusterrak nodoetan funtzionatzen du bereziki.
RAID benetan nahi duzun egoera batean (adibidez, kluster txikietan hainbat hutsegite onartzen dituen eszenatoki batean), ezerk ez dizu eragozten tokiko RAID kontrolagailuak erabiltzea eta biltegiratze hedatua eta RAIN arkitektura gainean eraikitzea. Eszenatoki hau nahiko bizia da eta guk onartzen dugu, beraz, vAIR erabiltzeko agertoki tipikoei buruzko artikulu batean hitz egingo dugu.
Biltegiratze akatsen tolerantzia-eskemak
Bi akatsen tolerantzia-eskema egon daitezke vAIR-en disko birtualetan:
1) Erreplikazio-faktorea edo, besterik gabe, erreplikazioa - akatsen tolerantzia metodo hau makila eta soka bezain erraza da. Erreplikazio sinkronikoa 2 (2 kopia kluster bakoitzeko) edo 3 (3 kopia, hurrenez hurren) duten nodoen artean egiten da. RF-2-k disko birtual batek klusterreko nodo baten porrota jasateko aukera ematen du, baina bolumen erabilgarriaren erdia "jaten" du, eta RF-3-k klusterreko 2 nodoren porrota jasango du, baina 2/3 erreserbatzen ditu. bere beharretarako bolumen erabilgarria. Eskema hau RAID-1-en oso antzekoa da, hau da, RF-2n konfiguratutako disko birtual bat klusterreko edozein nodoren hutsegitearekiko erresistentea da. Kasu honetan, dena ondo egongo da datuekin eta I/O ere ez da geldituko. Eroritako nodoa zerbitzura itzultzen denean, datuen berreskuratze/sinkronizazio automatikoa hasiko da.
Jarraian, RF-2 eta RF-3 datuen banaketaren adibideak daude modu normalean eta hutsegite egoeran.
Datu esklusibo (erabilgarri) 8MB-ko edukiera duen makina birtual bat dugu, 4 vAIR nodotan exekutatzen dena. Argi dago errealitatean nekez izango dela hain bolumen txikia, baina ARDFS funtzionamenduaren logika islatzen duen eskema batentzat, adibide hau da ulergarriena. AB 4 MBko bloke birtualak dira, makina birtualeko datu bakarrak dituztenak. RF-2-k A1+A2 eta B1+B2 bloke hauen bi kopia sortzen ditu, hurrenez hurren. Bloke hauek nodoen artean "plantatzen" dira, datu berdinen gurutzaketa nodo berean saihestuz, hau da, A1 kopia ez da A2 kopiaren nodo berean kokatuko. Berdin B1 eta B2-rekin.
Nodoetako batek huts egiten badu (adibidez, 3. nodoa, B1 kopia bat daukana), kopia hori automatikoki aktibatuko da bere kopiaren kopiarik ez dagoen nodoan (hau da, B2ren kopia bat).
Horrela, disko birtualak (eta VM, horren arabera) erraz biziraun dezake RF-2 eskemako nodo baten hutsegitetik.
Erreplikazio-eskemak, sinplea eta fidagarria den arren, RAID1-en arazo bera jasaten du: ez da nahikoa espazio erabilgarririk.
2) Ezabatze-kodeketa edo ezabatze-kodeketa («kode erredundantea», «ezabaketa-kodeketa» edo «erredundantzia-kode» izenez ere ezaguna) existitzen da goiko arazoa konpontzeko. EC erredundantzia-eskema bat da, eta datuen erabilgarritasun handia eskaintzen du disko-espazio txikiagoarekin erreplikarekin alderatuta. Mekanismo honen funtzionamendu-printzipioa RAID 5, 6, 6P-ren antzekoa da.
Kodetzean, EC prozesuak bloke birtual bat (4MB lehenespenez) hainbat "datu zati" txikiagotan banatzen du EC eskemaren arabera (adibidez, 2+1 eskema batek 4MB bloke bakoitza 2MB zatitan banatzen du). Ondoren, prozesu honek "parekidetasun zatiak" sortzen ditu "datu zatiak" aurretik banatutako zatietako bat baino handiagoak ez direnak. Deskodetzean, EC-k falta diren zatiak sortzen ditu "bizirik dauden" datuak kluster osoan irakurriz.
Esate baterako, 2 + 1 EC eskema duen disko birtual batek, 4 klusterreko nodoetan ezarrita, erraz jasango du klusterreko nodo baten porrota RF-2-ren modu berean. Kasu honetan, gastu orokorrak txikiagoak izango dira, bereziki, RF-2rako gaitasun-koefiziente erabilgarria 2koa da, eta EC 2+1erako 1,5ekoa.
Sinpleago deskribatzeko, funtsa bloke birtuala 2-8 (zergatik 2tik 8ra, ikusi behean) "pieza"tan banatzen da, eta pieza horietarako antzeko bolumeneko parekotasun "zatiak" kalkulatzen dira.
Ondorioz, datuak eta parekotasuna berdin banatzen dira klusterreko nodo guztietan. Aldi berean, erreplikarekin gertatzen den bezala, ARDFS-k automatikoki banatzen ditu datuak nodoen artean, datu berdinak (datuen kopiak eta haien parekotasuna) nodo berean gordetzea eragozteko, ondorioz datuak galtzeko aukera ezabatzeko. Izan ere, datuak eta haien parekotasuna huts egiten duen biltegiratze-nodo batean amaituko direla bat-batean.
Jarraian adibide bat dago, 8 MBko makina birtual berarekin eta 4 nodorekin, baina EC 2+1 eskema batekin.
A eta B blokeak 2 MBko bi zatitan banatzen dira (bi 2+1 direlako), hau da, A1+A2 eta B1+B2. Erreplika bat ez bezala, A1 ez da A2-ren kopia bat, A bloke birtual bat da, bi zatitan banatuta, B blokearekin berdina. Guztira, 4MB-ko bi multzo lortuko ditugu, bakoitzak bi MB-ko bi pieza ditu. Ondoren, multzo horietako bakoitzerako, parekotasuna pieza bat baino gehiagoko bolumenarekin kalkulatzen da (hau da, 2 MB), parekotasun gehigarri bat + 2 pieza lortzen dugu (AP eta BP). Guztira 4×2 datuak + 2×2 parekotasuna ditugu.
Ondoren, piezak nodoen artean "jartzen" dira, datuak haien parekotasunarekin gurutza ez daitezen. Horiek. A1 eta A2 ez dira APren nodo berean egongo.
Nodo baten (adibidez, hirugarrena ere) hutsegiterik gertatuz gero, eroritako B1 blokea automatikoki berrezartuko da BP parekotasunetik, zeina 2. zenbakiko nodoan gordetzen den, eta dagoen nodoan aktibatuko da. B-parekotasunik ez, alegia. BP zatia. Adibide honetan, 1. nodoa da
Ziur nago irakurleak galdera bat duela:
"Deskribatu duzun guztia aspaldi inplementatu dute lehiakideek eta kode irekiko soluzioetan, zein da EC-a ARDFSn inplementatzearen artean?"
Eta gero ARDFSren ezaugarri interesgarriak egongo dira.
Ezabatu kodeketa malgutasuna ardatz hartuta
Hasieran, EC X+Y eskema nahiko malgua eman genuen, non X 2tik 8rako zenbaki baten berdina den eta Y 1etik 8rako zenbaki baten berdina den, baina beti X baino txikiagoa edo berdina den. Eskema hau ematen da. malgutasunagatik. Bloke birtuala banatzen den datuen (X) kopurua handitzeak kostu orokorrak murriztea ahalbidetzen du, hau da, espazio erabilgarria handitzea.
Paritate zatien (Y) kopurua handitzeak disko birtualaren fidagarritasuna areagotzen du. Zenbat eta Y balioa handiagoa izan, orduan eta nodo gehiagok huts egin dezakete klusterrean. Noski, parekotasun-bolumena handitzeak ahalmen erabilgarria murrizten du, baina hau fidagarritasunarengatik ordaindu beharreko prezioa da.
Errendimenduaren menpekotasuna EC zirkuituekiko ia zuzena da: zenbat eta "pieza gehiago", orduan eta errendimendu txikiagoa; hemen, noski, ikuspegi orekatua behar da.
Planteamendu honi esker, administratzaileek biltegiratze hedatua konfigura dezakete malgutasun handienarekin. ARDFS igerilekuaren barruan, akatsen tolerantziarako edozein eskema eta haien konbinazioak erabil ditzakezu, eta hori, gure ustez, oso erabilgarria ere bada.
Jarraian, RF eta EC eskema batzuk (ez posible guztiak) alderatzen dituen taula dago.
Taulak erakusten du EC 8+7 konbinaziorik "terry"enak ere, zeinak kluster batean gehienez 7 nodo galtzea ahalbidetzen duena aldi berean, erreplikazio estandarra baino espazio erabilgarri gutxiago "jaten" duela (1,875 versus 2) eta 7 aldiz hobeto babesten duela. , eta horrek babes-mekanismo hau, konplexuagoa bada ere, askoz erakargarriagoa egiten du diskoko espazio mugatuko baldintzetan fidagarritasun handiena bermatu behar den egoeretan. Aldi berean, X edo Y-ren "plus" bakoitza errendimendu gehigarri bat izango dela ulertu behar duzu, beraz, fidagarritasunaren, aurrezpenaren eta errendimenduaren arteko triangeluan arreta handiz aukeratu behar duzu. Hori dela eta, aparteko artikulu bat eskainiko dugu kodeen tamaina ezabatzera.
Fidagarritasuna eta autonomia fitxategi-sistema
ARDFS lokalean exekutatzen da klusterreko nodo guztietan eta sinkronizatzen ditu bere bitartekoak erabiliz Ethernet interfaze dedikatuen bidez. Garrantzitsua da ARDFS-k modu independentean sinkronizatzen dituela datuak ez ezik, biltegiratzearekin lotutako metadatuak ere. ARDFS-en lanean ari ginenean, lehendik zeuden hainbat soluzio aztertu genituen aldi berean eta aurkitu genuen askok fitxategi-sistemaren meta sinkronizatzen dutela kanpoko DBMS banatu bat erabiliz, sinkronizaziorako ere erabiltzen duguna, baina konfigurazioak bakarrik, ez FS metadatuak (honi eta erlazionatutako beste azpisistema batzuei buruz). hurrengo artikuluan).
Kanpoko DBMS bat erabiliz FS metadatuak sinkronizatzea, noski, funtzionatzeko irtenbide bat da, baina gero ARDFSn gordetako datuen koherentzia kanpoko DBMSaren eta bere portaeraren araberakoa izango litzateke (eta, egia esanda, dama kapritxoso bat da), hau da. gure iritzia txarra da. Zergatik? FS metadatuak hondatzen badira, FS datuak bera ere "agur" esan daiteke, beraz, bide konplexuago baina fidagarriagoa hartzea erabaki dugu.
ARDFSrako metadatuak sinkronizatzeko azpisistema guk geuk egin genuen, eta ondoko azpisistemetatik erabat independentean bizi da. Horiek. beste azpisistema batek ezin ditu ARDFS datuak hondatu. Gure ustez, hau da biderik fidagarriena eta zuzenena, baina denborak esango du hori benetan hala den. Gainera, ikuspegi honekin abantaila gehigarri bat dago. ARDFS vAIR-tik independentean erabil daiteke, biltegiratze luzatua bezala, etorkizuneko produktuetan zalantzarik gabe erabiliko duguna.
Ondorioz, ARDFS garatuz, fitxategi-sistema malgu eta fidagarri bat jaso genuen, non ahalmena aurrezteko edo errendimenduan dena uzteko, edo biltegiratze ultra fidagarria egiteko arrazoizko kostuarekin, baina errendimendu-eskakizunak murriztuz.
Lizentzia-politika soil batekin eta entrega-eredu malgu batekin batera (aurrera begira, vAIR nodoen lizentzia du, eta software gisa edo software pakete gisa entregatzen da), horrek aukera ematen dizu soluzioa oso zehatz egokitzeko bezeroen eskakizun askotara eta orduan erraz mantendu oreka hori.
Nork behar du mirari hau?
Alde batetik, esan dezakegu dagoeneko badirela merkatuan hiperkonbergentziaren alorrean irtenbide serioak dituzten eragileak, eta horra goazela benetan. Badirudi baieztapen hau egia dela, BAINA...
Bestalde, soroetara atera eta bezeroekin komunikatzen garenean, guk eta gure bazkideek ikusten dugu hori ez dela batere horrela. Hiperkonbergentziarako zeregin asko daude, leku batzuetan jendeak ez zekien horrelako konponbideak existitzen zirenik, beste batzuetan garestia zirudien, beste batzuetan irtenbide alternatiboen proba arrakastatsuak egon ziren eta beste batzuetan erostea debekatzen dute zigorrengatik. Oro har, zelaia goldatu gabe geratu zen, beraz, lur birjina altxatzera joan ginen))).
Noiz da biltegiratze sistema GCS baino hobea?
Merkatuarekin lan egiten dugunez, askotan galdetzen digute noiz den hobe biltegiratze sistemekin eskema klasiko bat erabiltzea, eta noiz erabili hiperkonbergenteak? GCS ekoizten duten enpresa askok (batez ere beren zorroan biltegiratze-sistemarik ez dutenek) esaten dute: "Biltegiratze-sistemak zaharkituta geratzen ari dira, hiperkonbergenteak soilik!" Adierazpen ausarta da, baina ez du errealitatea guztiz islatzen.
Egia esan, biltegiratze-merkatua hiperkonbergentzia eta antzeko irtenbideetara doa, baina beti dago "baina".
Lehenik eta behin, biltegiratze-sistemekin eskema klasikoaren arabera eraikitako datu-zentroak eta informatika-azpiegiturak ezin dira erraz berreraiki, beraz, azpiegitura horiek modernizatzea eta osatzea 5-7 urterako ondarea da oraindik.
Bigarrenik, gaur egun gehienetan eraikitzen ari diren azpiegiturak (Errusiar Federazioa esan nahi du) biltegiratze sistemak erabiliz eskema klasikoaren arabera eraikitzen dira, eta ez jendeak hiperkonbergentziaz ez dakiela, baizik eta hiperkonbergentziaren merkatua berria delako, irtenbideak eta estandarrak oraindik ez dira ezarri, IT-ak ez daude oraindik trebatuak, esperientzia gutxi dute, baina datu-zentroak eraiki behar dituzte orain eta hemen. Eta joera honek beste 3-5 urte iraungo du (eta gero beste ondare bat, ikus 1. puntua).
Hirugarrenik, muga tekniko hutsa dago idazketa bakoitzeko 2 milisegundoko atzerapen txiki gehigarrietan (tokiko cachea kenduta, noski), biltegiratze banatuaren kostua direnak.
Beno, ez dezagun ahaztu diskoaren azpisistemaren eskalatze bertikala maite duten zerbitzari fisiko handien erabileraz.
Biltegiratze-sistemek GCS baino hobeto jokatzen duten zeregin beharrezkoak eta ezagunak daude. Hemen, noski, produktuen zorroan biltegiratze sistemarik ez duten fabrikatzaileek ez dute gurekin ados egongo, baina prest gaude arrazoiz argudiatzeko. Jakina, guk, bi produktuen garatzaileek, biltegiratze sistemak eta GCS konparatuko ditugu zalantzarik gabe gure etorkizuneko argitalpenetako batean, non argi eta garbi frogatuko dugun zein den hobea zein baldintzatan.
Eta non funtzionatuko dute soluzio hiperkonbergatuek biltegiratze sistemek baino hobeto?
Aurreko puntuetatik abiatuta, hiru ondorio argi atera daitezke:
- Grabatzeko 2 milisegundoko latentzia gehigarri bat, edozein produktutan koherentziaz gertatzen dena (orain ez gara sintetikoez ari, nanosegundoak sintetikoetan erakutsi daitezke), kritikoak ez direnean, hiperkonbergentea egokia da.
- Zerbitzari fisiko handien karga birtual txiki asko bihur daitekeen eta nodoen artean banatu daitekeenean, hiperkonbergentzia ere ondo funtzionatuko du.
- Eskalatze horizontala eskalatze bertikala baino lehentasun handiagoa denean, GCS-k ondo egingo du hor ere.
Zeintzuk dira irtenbide hauek?
- Azpiegitura zerbitzu estandar guztiak (direktorio-zerbitzua, posta, EDMS, fitxategi-zerbitzariak, ERP eta BI sistema txiki edo ertainak, etab.). Horri “informatika orokorra” deitzen diogu.
- Hodeiko hornitzaileen azpiegitura, non bezeroentzako makina birtual kopuru handi bat azkar eta estandarizatu horizontalki zabaldu eta erraz "moztu" behar den.
- Mahaigaineko azpiegitura birtuala (VDI), non erabiltzaile txikien makina birtual asko exekutatzen eta isilean "flotatzen" dira kluster uniforme baten barruan.
- Sukurtsal-sareak, non adar bakoitzak 15-20 makina birtualeko azpiegitura estandar, tolerantea eta merkea behar baitu.
- Banatutako edozein informatika (big data zerbitzuak, adibidez). Non karga ez doan "sakonean", "zabalean" baizik.
- Atzerapen txiki gehigarriak onargarriak diren proba-inguruneak, baina aurrekontu-murrizketak daude, probak direlako.
Momentuz, zeregin horietarako egin dugu AERODISK vAIR eta horietara bideratzen ari gara (orain arte arrakastaz). Agian hau laster aldatuko da, zeren... mundua ez da geldi.
Beraz ...
Honek artikulu sorta handi baten lehen zatia osatzen du; hurrengo artikuluan irtenbidearen arkitekturaz eta erabilitako osagaiez hitz egingo dugu.
Galderak, iradokizunak eta gatazka eraikitzaileak onartzen ditugu.
Iturria: www.habr.com