Datu zentroen sarearen diseinua garatu dugu, 100 mila zerbitzari baino handiagoak diren informatika-klusterrak hedatzea ahalbidetzen duena, segundoko petabyte bat baino gehiagoko bisekzioko banda zabalera gailurrarekin.
Dmitry Afanasyev-en txostenetik diseinu berriaren oinarrizko printzipioak ezagutuko dituzu, topologiak eskalatzea, honekin sortzen diren arazoak, horiek konpontzeko aukerak, bideratzearen eta sareko gailu modernoen birbidaltze-planoaren funtzioak "dentsitate konektatuetan" eskalatzeko ezaugarriak. ECMP ibilbide kopuru handia duten topologiak . Horrez gain, Dimak laburki hitz egin zuen kanpoko konektibitatearen antolaketaz, geruza fisikoaz, kableatu sistemaz eta ahalmena are gehiago handitzeko moduez.
- Arratsalde on guztioi! Nire izena Dmitry Afanasyev da, Yandex-en sareko arkitektoa naiz eta batez ere datu zentroen sareak diseinatzen ditut.
Nire istorioa Yandex datu-zentroen sare eguneratuari buruzkoa izango da. Guk genuen diseinuaren bilakaera bat da, baina aldi berean elementu berri batzuk daude. Aurkezpen orokorra da hau, denbora gutxian bildu beharreko informazio asko zegoelako. Topologia logiko bat aukeratzen hasiko gara. Ondoren, kontrol-planoaren eta datu-planoaren eskalagarritasun-arazoen ikuspegi orokorra izango da, maila fisikoan gertatuko denaren aukeraketa eta gailuen ezaugarri batzuk aztertuko ditugu. Ukitu dezagun pixka bat MPLS duen datu-zentro batean gertatzen ari dena, duela denbora pixka bat hitz egin genuenaz.
Beraz, zer da Yandex karga eta zerbitzuei dagokienez? Yandex hipereskalatzaile tipikoa da. Erabiltzaileei begiratzen badiegu, batez ere erabiltzaileen eskaerak prozesatzen ditugu. Baita hainbat streaming zerbitzu eta datu transferentzia ere, biltegiratze zerbitzuak ere baditugu. Backendetik gertuago badago, azpiegitura-kargak eta zerbitzuak agertzen dira bertan, hala nola banatutako objektuen biltegiratzea, datuen erreplikazioa eta, jakina, ilara iraunkorrak. Lan-karga mota nagusietako bat MapReduce eta antzeko sistemak, korronteen prozesamendua, ikaskuntza automatikoa, etab.
Nola dago hori guztia gertatzen den azpiegitura? Berriz ere, nahiko hipereskalatzaile tipikoa gara, nahiz eta agian espektroaren hipereskalatzaile txikiagotik pixka bat hurbilago gauden. Baina ezaugarri guztiak ditugu. Ahal den guztietan oinarrizko hardwarea eta eskalatze horizontala erabiltzen ditugu. Baliabideen bilketa osoa dugu: ez dugu makina indibidualekin lan egiten, banakako bastidorekin, baizik eta baliabide trukagarrien multzo handi batean konbinatzen ditugu plangintza eta esleipena lantzen dituzten zerbitzu osagarri batzuekin, eta igerileku oso honekin lan egiten dute.
Beraz, hurrengo maila dugu - informatika-kluster mailan sistema eragilea. Oso garrantzitsua da erabiltzen dugun teknologia pila guztiz kontrolatzea. Amaiera-puntuak (ostalariak), sare eta software pila kontrolatzen ditugu.
Hainbat datu-zentro handi ditugu Errusian eta atzerrian. MPLS teknologia darabilten bizkarrezurraz batzen dira. Gure barne-azpiegitura IPv6-n eraikita dago ia erabat, baina oraindik batez ere IPv4-tik datorren kanpoko trafikoa zerbitzatu behar dugunez, nolabait IPv4-tik datozen eskaerak frontend zerbitzarietara bidali behar ditugu, eta pixka bat gehiago kanpoko IPv4-Internetera joan behar dugu. adibidez, indexatzeko.
Datu-zentroen sarearen diseinuen azken iterazioek geruza anitzeko Clos topologiak erabili dituzte eta L3 soilik dira. Duela pixka bat L2 utzi eta lasai hartu genuen arnasa. Azkenik, gure azpiegiturak ehunka mila konputazio (zerbitzari) instantzia ditu. Klusterren gehienezko tamaina duela denbora pixka bat 10 mila zerbitzari ingurukoa zen. Hau da, neurri handi batean, kluster-mailako sistema eragile, programatzaile, baliabideen esleipen eta abar berdin horiek nola funtziona dezaketen. Azpiegitura softwarearen aldetik aurrerapena gertatu denez, helburuen tamaina 100 mila zerbitzari ingurukoa da orain informatika-kluster batean, eta Zeregin bat dugu: horrelako kluster batean baliabideen bilketa eraginkorra ahalbidetzen duten sare-fabrikak eraiki ahal izatea.
Zer nahi dugu datu-zentro sare batetik? Lehenik eta behin, banda-zabalera merkea eta nahiko uniformeki banatua dago. Sarea baita baliabideak biltzeko euskarria. Helburu-tamaina berria 100 mila zerbitzari ingurukoa da kluster batean.
Guk ere, noski, kontrol-plano eskalagarria eta egonkorra nahi dugu, hain azpiegitura handi batean buruhauste asko sortzen direlako ausazko gertakarietatik ere, eta ez dugu nahi kontrol-hegazkinak ere buruhausterik ekar diezagunik. Aldi berean, bertan dagoen egoera gutxitu nahi dugu. Zenbat eta txikiagoa izan egoera, orduan eta hobeto eta egonkorrago funtzionatzen du dena, eta orduan eta errazagoa da diagnostikatzea.
Noski, automatizazioa behar dugu, ezinezkoa baita halako azpiegitura bat eskuz kudeatzea, eta denbora luzez ezinezkoa da. Laguntza operatiboa behar dugu ahal den neurrian eta CI/CD laguntza eman daitekeen neurrian.
Datu-zentroen eta klusterren tamaina horiekin, inplementazio eta hedapen inkrementalak babesteko zeregina nahiko zorrotza bihurtu da. Mila makinako tamainako multzoetan, agian hamar mila makinatik gertu, oraindik eragiketa bakarrean heda litezke; hau da, azpiegituraren hedapena planifikatzen ari gara, eta hainbat mila makina eragiketa bakarrean gehitzen dira. orduan ehun mila makinako tamainako multzo bat ez da horrela berehala sortzen, denbora tarte batean eraikitzen da. Eta desiragarria da denbora honetan guztian lehendik ateratakoa, zabaldutako azpiegiturak, eskuragarri egotea.
Eta guk genuen eta utzi genuen baldintza bat: maiztasun anitzeko euskarria, hau da, birtualizazioa edo sarearen segmentazioa. Orain ez dugu hau sare-ehunaren mailan egin behar, zatiketa ostalariengana joan delako, eta horrek eskalatzea oso erraza egin digulako. IPv6ri eta helbide-espazio handi bati esker, ez genuen helbide bikoiztuak erabili behar barne azpiegituran; helbideratze guztiak bakarrak ziren jada. Eta ostalariei iragazketa eta sarearen segmentazioa eraman diegunari esker, ez dugu datu-zentroen sareetan sare birtual entitaterik sortu beharrik.
Oso gauza garrantzitsua da behar ez duguna. Funtzio batzuk saretik ken daitezke, horrek bizitza asko errazten du, eta, oro har, eskuragarri dauden ekipoen eta softwarearen aukera zabaltzen du, diagnostikoak oso errazak eginez.
Beraz, zer da behar ez duguna, zeri uko egin ahal izan diogu, ez beti pozarekin gertatu zen unean, baina prozesua amaitutakoan lasaitasun handiz?
Lehenik eta behin, L2 alde batera utzita. Ez dugu L2 behar, ez erreala ez imitatua. Erabili gabea, neurri handi batean, aplikazioen pila kontrolatzen dugulako. Gure aplikazioak horizontalki eskalagarriak dira, L3 helbideratzearekin funtzionatzen dute, ez dute oso kezkatzen instantzia indibidual bat desagertu izanak, berri bat zabaltzen dute, ez da helbide zaharrean zabaldu behar, bat dagoelako. klusterrean kokatutako makinen zerbitzuen aurkikuntza eta monitorizazio maila bereizia. Ez dugu zeregin hori sarean eskuordetzen. Sarearen lana paketeak A puntutik B puntura bidaltzea da.
Helbideak sarearen barruan mugitzen diren egoerarik ere ez dugu, eta horren jarraipena egin behar da. Diseinu askotan hori behar da normalean VM mugikortasuna laguntzeko. Yandex handiaren barne-azpiegituretan ez dugu makina birtualen mugikortasuna erabiltzen, eta, gainera, uste dugu hori eginda ere, sareko euskarriarekin ez dela gertatu behar. Benetan egin behar baduzu, ostalariaren mailan egin behar duzu, eta gainjartzeetara migra daitezkeen helbideak bultzatu, azpiko geruza beraren bideratze-sisteman (garraio-sarea) aldaketa dinamiko gehiegi ez ukitzeko edo egiteko. .
Erabiltzen ez dugun beste teknologia bat multicast da. Nahi baduzu, zehatz-mehatz esan dezaket zergatik. Horrek bizitza askoz errazten du, zeren norbaitek horri aurre egin eta multicast kontrol-planoa nolakoa den ikusi badu, instalazio guztietan izan ezik, hau buruhauste handia da. Eta are gehiago, zaila da kode irekiko inplementazio ondo funtzionatzen duen bat aurkitzea, adibidez.
Azkenik, gure sareak diseinatzen ditugu gehiegi aldatu ez daitezen. Bideratze sisteman kanpoko gertaeren fluxua txikia dela zenbatu dezakegu.
Zer arazo sortzen dira eta zer murrizketa hartu behar dira kontuan datu zentroen sarea garatzen dugunean? Kostua, noski. Eskalagarritasuna, hazi nahi dugun maila. Zerbitzua eten gabe zabaldu beharra. Banda zabalera, erabilgarritasuna. Sarean gertatzen denaren ikusgarritasuna monitorizazio sistemetarako, talde operatiboetarako. Automatizazio-laguntza - berriro ere, ahal den neurrian, zeregin desberdinak maila ezberdinetan ebatzi daitezkeelako, geruza gehigarriak sartzea barne. Beno, ez [baliteke] saltzaileen menpe. Garai historiko ezberdinetan egon arren, zein atal begiratuta, independentzia hori errazagoa edo zailagoa zen lortzea. Sareko gailuen txip-atal bat hartzen badugu, orain gutxi arte oso baldintzatua zegoen saltzaileekiko independentziaz hitz egitea, errendimendu handiko txipak ere nahi baditugu.
Zein topologia logiko erabiliko dugu gure sarea eraikitzeko? Hau maila anitzeko Clos bat izango da. Izan ere, momentuz ez dago benetako alternatibarik. Eta Clos topologia nahiko ona da, nahiz eta orain interes akademikoaren eremuan dauden hainbat topologia aurreratuekin alderatuta, etengailu erradikal handiak baditugu.
Nola egituratzen da maila anitzeko Clos sare bat gutxi gorabehera eta nola deitzen dira bertan elementu ezberdinei? Lehenik eta behin, haize-arrosa, orientatzeko non dagoen iparraldea, non hegoa, non ekialdea, non mendebaldea. Mota honetako sareak mendebalde-ekialdeko trafiko oso handia dutenek eraiki ohi dituzte. Gainerako elementuei dagokienez, goialdean etengailu txikiagoetatik muntatutako etengailu birtual bat dago. Hau da Clos sareen eraikuntza errekurtsiboaren ideia nagusia. Erradix motaren bat duten elementuak hartzen ditugu eta konektatzen ditugu, lortzen duguna erradizo handiagoko etengailutzat har dadin. Are gehiago behar baduzu, prozedura errepikatu daiteke.
Kasuetan, adibidez, bi mailako Clos-ekin, nire diagraman bertikalak diren osagaiak argi identifikatzea posible denean, plano deitzen zaie normalean. Clos bat eraikiko bagenu bizkarrezurreko etengailuen hiru maila dituena (guztiak ez dira muga edo ToR etengailuak eta garraiorako soilik erabiltzen direnak), orduan hegazkinek konplexuagoak izango lirateke; bi mailatakoak hain zuzen. ToR edo hostoen etengailuen blokeari eta haiekin lotutako lehen mailako bizkarrezurreko etengailuei Pod deitzen diegu. Podaren goiko aldean dauden bizkarrezurreko 1 mailako bizkarrezurreko etengailuak Podaren goiko aldea dira, Podaren goiko aldea. Fabrika osoaren goialdean dauden etengailuak fabrikaren goiko geruza dira, Top of fabric.
Jakina, galdera sortzen da: Clos sareak aspalditik eraiki dira; ideia bera, oro har, telefonia klasikoaren garaietatik dator, TDM sareak. Agian zerbait hobea agertu da, agian zerbait hobeto egin daiteke? Bai eta ez. Teorian bai, praktikan etorkizun hurbilean behin betiko ez. Topologia interesgarri ugari daudenez, horietako batzuk produkzioan ere erabiltzen dira, adibidez, Dragonfly HPC aplikazioetan erabiltzen da; Topologia interesgarriak ere badaude, hala nola Xpander, FatClique, Jellyfish. Duela gutxi SIGCOMM edo NSDI bezalako kongresuetako txostenak aztertzen badituzu, Clos-ek baino propietate hobeak (bat edo beste) dituzten topologia alternatiboei buruzko lan kopuru handi samarra aurki dezakezu.
Baina topologia hauek guztiek propietate interesgarri bat dute. Datu-zentroen sareetan ezartzea eragozten du, oinarrizko hardwarean eraikitzen saiatzen ari garen eta nahiko arrazoizko dirua balio dutenak. Topologia alternatibo hauetan guztietan, banda-zabalera gehiena, zoritxarrez, ez da bide laburrenetatik iristen. Horregatik, berehala galtzen dugu ohiko kontrol-hegazkina erabiltzeko aukera.
Teorian, arazoaren konponbidea ezagutzen da. Hauek dira, adibidez, lotura-egoeraren aldaketak k-bide laburrenak erabiliz, baina, berriro ere, ez dago produkzioan inplementatuko litzatekeen protokolorik eta ekipamenduetan eskuragarri egongo denik.
Gainera, ahalmen gehiena bide laburrenen bidez irisgarri ez denez, kontrol-planoa baino gehiago aldatu behar dugu bide horiek guztiak hautatzeko (eta, bide batez, kontrol-planoan egoera nabarmenagoa da). Bidalketa-planoa aldatu behar dugu oraindik, eta, oro har, gutxienez bi ezaugarri osagarri behar dira. Hau da paketeen birbidaltzeari buruzko erabaki guztiak behingoz hartzeko gaitasuna, adibidez, ostalarian. Izan ere, hau iturburu-bideraketa da, batzuetan interkonexio-sareei buruzko literaturan hori deitzen zaio bat-batean birbidaltzeko erabakiak. Eta bideratze moldagarria sareko elementuetan behar dugun funtzio bat da, hau da, adibidez, ilararen karga gutxienari buruzko informazioan oinarrituta hurrengo saltoa hautatzen dugula. Adibide gisa, beste aukera batzuk posible dira.
Beraz, norabidea interesgarria da, baina, tamalez, ezin dugu oraintxe aplikatu.
Ados, Clos topologia logikoan finkatu gara. Nola eskalatuko dugu? Ikus dezagun nola funtzionatzen duen eta zer egin daitekeen.
Clos sare batean bi parametro nagusi daude, nolabait aldatu eta emaitza jakin batzuk lortu ditzakegunak: elementuen erradizoa eta sareko maila kopurua. Biek tamainan eragiten duten eskema eskematiko bat daukat. Egokiena, biak uztartzen ditugu.
Ikus daiteke Clos sarearen azken zabalera hegoaldeko erradizoko bizkarrezurreko etengailuen maila guztien produktua dela, zenbat lotura ditugun behera, nola adarkatzen den. Horrela eskalatzen dugu sarearen tamaina.
Ahalmenari dagokionez, batez ere ToR etengailuetan, bi eskalatzeko aukera daude. Edo, topologia orokorra mantenduz, lotura azkarragoak erabil ditzakegu, edo plano gehiago gehi ditzakegu.
Clos sarearen bertsio zabaldua begiratuz gero (beheko eskuineko izkinan) eta argazki honetara itzultzen bazara behean Clos sarearekin...
... orduan hau topologia bera da, baina diapositiba honetan trinkoago tolesten da eta fabrikako planoak elkarren gainean jartzen dira. Berdin da.
Nolakoa da Clos sare bat eskalatzea zenbakietan? Hemen sare bat zein zabalera maximoa lor daitekeen, zein gehienezko bastidore, ToR etengailu edo hosto etengailu kopuruari buruzko datuak ematen ditut, bastidoreetan ez badaude, bizkarrezurreko mailetarako erabiltzen ditugun etengailuen zein erradixaren arabera lor dezakegu, eta zenbat maila erabiltzen ditugun.
Hona hemen zenbat rack izan ditzakegun, zenbat zerbitzari eta gutxi gorabehera zenbat kontsumitu dezakeen honek guztiak rack bakoitzeko 20 kW-en arabera. Apur bat lehenago aipatu nuen 100 mila zerbitzari inguruko kluster tamainaren helburua dugula.
Ikusten denez, diseinu honetan bi aukera eta erdi interesgarriak dira. Bi geruza bizkarrezurra eta 64 ataka etengailu dituen aukera bat dago, pixka bat motz geratzen dena. Ondoren, bi maila dituzten 128 atakako (128 erradizoarekin) bizkarrezurreko etengailuetarako aukera ezin hobeak daude, edo hiru mailarekin 32 erradikala duten etengailuetarako. Eta kasu guztietan, erradix eta geruza gehiago dauden tokietan, sare oso handia egin dezakezu, baina espero den kontsumoari erreparatuz gero, normalean gigawatt egoten dira. Posible da kable bat jartzea, baina nekez lortuko dugu horrenbeste elektrizitate gune batean. Datu-zentroei buruzko estatistikak eta datu publikoak aztertzen badituzu, datu-zentro gutxi aurki ditzakezu 150 MW-tik gorako potentzia estimatua dutenak. Handienak datu-zentroen campusak izan ohi dira, elkarrengandik nahiko gertu dauden hainbat datu-zentro handi.
Bada beste parametro garrantzitsu bat. Ezkerreko zutabera begiratzen baduzu, banda-zabalera erabilgarria hor zerrendatzen da. Erraz ikusten da Clos sare batean portuen zati garrantzitsu bat etengailuak elkarren artean konektatzeko erabiltzen dela. Banda zabalera erabilgarria, banda erabilgarria, kanpoan eman daitekeen zerbait da, zerbitzarietara. Berez, baldintzapeko portuez ari naiz eta, zehazki, bandaz. Oro har, sare barruko estekak zerbitzarietarako estekak baino azkarragoak dira, baina banda-zabalera unitateko, gure zerbitzari-ekipoetara bidal ditzakegun neurrian, sarean bertan banda zabalera bat dago oraindik. Eta zenbat eta maila gehiago egin, orduan eta handiagoa izango da marra hori kanpoaldera hornitzearen kostu espezifikoa.
Gainera, banda gehigarri hau ere ez da guztiz berdina. Tarteak laburrak diren arren, DAC (zuzeneko kobrea, hau da, twinax kableak) edo modu anitzeko optika bezalako zerbait erabil dezakegu, diru gehiago edo gutxiago balio duena. Espazio luzeagoetara mugitzen garen bezain laster, oro har, modu bakarreko optika dira, eta banda-zabalera gehigarri horren kostua nabarmen handitzen da.
Eta berriro, aurreko diapositiba itzuliz, Clos sare bat gehiegizko harpidetzarik gabe sortzen badugu, orduan erraza da diagrama ikustea, sarea nola eraikitzen den ikustea - bizkarrezurreko etengailuen maila bakoitza gehituz, zerrenda osoa errepikatuko dugu. behean. Plus maila - gehi banda bera, aurreko mailan zeuden etengailuetan ataka kopuru bera eta transceptor kopuru bera. Hori dela eta, oso desiragarria da bizkarrezurreko etengailuen maila kopurua murriztea.
Irudi honetan oinarrituta, argi dago benetan 128ko erradizoa duten etengailuak bezalako zerbait eraiki nahi dugula.
Hemen, printzipioz, dena da esan berri dudanaren berdina; hau aurrerago aztertzeko diapositiba bat da.
Zein aukera daude etengailu gisa hauta ditzakegunak? Guretzat oso albiste atsegina da orain halako sareak azkenean txip bakarreko etengailuetan eraiki daitezkeela. Eta hau oso polita da, ezaugarri polit asko dituzte. Esaterako, ez dute ia barne egiturarik. Horrek esan nahi du errazago apurtzen direla. Modu guztietan apurtzen dira, baina zorionez guztiz apurtzen dira. Gailu modularetan akats ugari daude (oso desatsegina), bizilagunen eta kontrol-planoaren ikuspuntutik funtzionatzen ari dela dirudienean, baina, adibidez, ehunaren zati bat galdu da eta ez dabil. edukiera osoan. Eta bertarako trafikoa orekatua dago guztiz funtzionala dela eta gainkargatu gaitezke.
Edo, adibidez, atzeko planoarekin arazoak sortzen dira, gailu modularraren barruan abiadura handiko SerDes ere badaudelako - barruan benetan konplexua da. Bidaltzeko elementuen arteko seinaleak sinkronizatuta daude edo ez daude sinkronizatuta. Oro har, elementu kopuru handiz osatutako edozein gailu modular produktiboak, oro har, Clos sare bera dauka bere baitan, baina oso zaila da diagnostikatzea. Askotan zaila da saltzaileak berak diagnostikatzea.
Eta hutsegite agertoki ugari ditu, non gailua degradatzen den, baina topologiatik erabat erortzen ez den. Gure sarea handia denez, elementu berdinen arteko oreka aktiboki erabiltzen da, sarea oso erregularra da, hau da, dena ordenatuta dagoen bide bat ez da beste bidetik desberdina, errentagarriagoa da guretzat zati batzuk galtzea. topologiatik gailuak batzuk funtzionatzen dutela dirudien egoera batean bukatzea baino, beste batzuk ez.
Txip bakarreko gailuen hurrengo ezaugarri polita da hobeto eta azkarrago eboluzionatzen dutela. Gainera, gaitasun hobea izan ohi dute. Zirkulu batean ditugun muntatutako egitura handiak hartzen baditugu, orduan abiadura bereko portuetarako rack-unitate bakoitzeko edukiera gailu modularrena baino bi aldiz handiagoa da. Txip bakar baten inguruan eraikitako gailuak modularrak baino nabarmen merkeagoak dira eta energia gutxiago kontsumitzen dute.
Baina, noski, hau guztia arrazoi batengatik da, desabantailak ere badaude. Lehenik eta behin, erradizoa gailu modularrena baino txikiagoa da ia beti. 128 ataka dituen txip baten inguruan eraikitako gailu bat lor dezakegu, orduan ehunka portu dituen modular bat lor dezakegu orain arazorik gabe.
Hau birbidaltzeko taulen tamaina nabarmen txikiagoa da eta, oro har, datu-planoen eskalagarritasunarekin lotutako guztia. Azaleko tamponak. Eta, oro har, funtzionaltasun nahiko mugatua. Baina bihurtzen da murrizketa hauek ezagutzen badituzu eta garaiz saihesteko edo, besterik gabe, kontuan hartzen badituzu, hori ez da hain beldurgarria. Erradixa txikiagoa izatea jada ez da arazoa azkenaldian agertu diren 128 erradizoa duten gailuetan; bi bizkarrezurra geruzatan eraiki ditzakegu. Baina oraindik ezinezkoa da guretzat interesgarria den bi baino txikiagorik eraikitzea. Maila batekin, oso multzo txikiak lortzen dira. Gure aurreko diseinuek eta eskakizunek ere gainditzen zituzten.
Izan ere, bat-batean irtenbidea nonbait ertzean badago, oraindik badago eskalatzeko modurik. Zerbitzariak konektatzen diren azken (edo lehen) maila baxuena ToR etengailuak edo hostoen etengailuak direnez, ez dugu rack bat konektatu behar. Hori dela eta, konponbidea erdira gutxi gorabehera gutxi gorabehera, pentsa dezakezu beheko mailan erroda handia duen etengailua erabiltzea eta, adibidez, bi edo hiru bastidore etengailu batean konektatzea. Hau ere aukera bat da, bere kostuak ditu, baina nahiko ondo funtzionatzen du eta irtenbide ona izan daiteke tamainaren bikoitza lortu behar duzunean.
Laburbilduz, bi mailatako bizkarrezurra dituen topologia baten gainean eraikitzen ari gara, zortzi fabrika-geruza dituena.
Zer gertatuko da fisikarekin? Kalkulu oso sinpleak. Bizkarrezurra bi maila baditugu, orduan hiru etengailu maila baino ez ditugu, eta sarean hiru kable-segmentu egongo direla espero dugu: zerbitzarietatik hosto-etengailuetara, 1. bizkarrezurra, 2. bizkarrezurra. Ahal ditugun aukerak erabilera dira - hauek twinax, multimode, single mode dira. Eta hemen kontuan hartu behar dugu zer zerrenda dagoen eskuragarri, zenbat kostatuko den, zein dimentsio fisikoak diren, zer tarte estali ditzakegun eta nola berrituko dugun.
Kostuari dagokionez, dena lerrokatu daiteke. Twinaxak optika aktiboa baino nabarmen merkeagoak dira, modu anitzeko transzeitoreak baino merkeagoak, hegaldi bakoitzeko amaieratik hartzen badituzu, 100 gigabiteko switch ataka baino zertxobait merkeagoak. Kontuan izan, modu bakarreko optikak baino gutxiago kostatzen duela, zeren modu bakarra behar den hegaldietan datu-zentroetan arrazoi batzuengatik CWDM erabiltzea zentzuzkoa da, eta modu bakarre paraleloan (PSM) ez da oso erosoa lan egiteko. horrekin, pakete oso handiak lortzen dira zuntzak, eta teknologia horietan zentratzen bagara, gutxi gorabehera honako prezio hierarkia hau lortzen dugu.
Ohar bat gehiago: zoritxarrez, ez da oso posible desmuntatutako 100 eta 4x25 modu anitzeko atakak erabiltzea. SFP28 transceptoresen diseinu-ezaugarriengatik, ez da 28 Gbit QSFP100 baino askoz merkeagoa. Eta multimodorako desmuntatze honek ez du oso ondo funtzionatzen.
Beste muga bat da informatika-klusterren tamaina eta zerbitzari kopurua dela eta, gure datu-zentroak fisikoki handiak direla. Horrek esan nahi du gutxienez hegaldi bat singlemod batekin egin beharko dela. Berriz ere, Pods-en tamaina fisikoa dela eta, ezin izango dira bi twinax (kobrezko kableak) exekutatu.
Ondorioz, prezioa optimizatzen badugu eta diseinu honen geometria kontuan hartzen badugu, twinax span bat, span multimode bat eta span span monomode CWDM erabiliz lortuko ditugu. Honek berritze-bide posibleak hartzen ditu kontuan.
Honela dirudi duela gutxi, nora goazen eta zer den posible. Argi dago, behintzat, nola mugitu 50 Gigabit SerDeserantz bai multimodurako bai bakarrerako. Gainera, orain eta etorkizunean 400G-rako modu bakarreko transceptoreetan zer dagoen aztertzen baduzu, askotan 50G SerDes alderdi elektrikotik iristen direnean ere, 100 Gbps errei bakoitzeko optikara joan daitezke dagoeneko. Hori dela eta, litekeena da 50era pasa beharrean, 100 Gigabit SerDes eta 100 Gbps-ra errei bakoitzeko trantsizioa izatea, saltzaile askoren promesen arabera, haien erabilgarritasuna laster espero baita. 50G SerDes azkarrenak izan zireneko epea, antza, ez da oso luzea izango, 100G SerDesen lehen kopiak ia datorren urtean kaleratzen ari direlako. Eta denbora pixka bat igaro ondoren, ziurrenik arrazoizko dirua balioko dute.
Fisikaren aukeraketari buruzko Γ±abardura bat gehiago. Printzipioz, dagoeneko 400 edo 200 Gigabit atakak erabil ditzakegu 50G SerDes erabiliz. Baina ematen du horrek ez duela zentzu handirik, zeren, lehen esan bezala, etengailuetan erradix handi samarra nahi dugulako, arrazoiaren barruan, noski. 128 nahi dugu. Eta txip-ahalmen mugatua badugu eta lotura-abiadura handitzen badugu, orduan erradizoa naturalki gutxitzen da, ez dago miraririk.
Eta ahalmen osoa handitu dezakegu hegazkinak erabiliz, eta ez dago kostu berezirik; hegazkin kopurua gehitu dezakegu. Eta radix galtzen badugu, maila gehigarri bat sartu beharko dugu, beraz, egungo egoeran, txip bakoitzeko egungo gehienezko edukiera eskuragarriarekin, 100 gigabiteko atakak erabiltzea eraginkorragoa dela ematen du, aukera ematen dizutelako. radix handiagoa lortzeko.
Hurrengo galdera da fisika nola antolatzen den, baina kable azpiegituren ikuspuntutik. Modu barregarri samarrean antolatuta dagoela ematen du. Hosto-etengailuen eta lehen mailako bizkarrezurra arteko kableatzea - ββez dago lotura askorik, dena nahiko sinplea da. Baina hegazkin bat hartzen badugu, barruan gertatzen dena da lehen mailako bizkarrezurra guztiak bigarren mailako bizkarrezurra guztiak lotu behar ditugula.
Gainera, oro har, datu-zentroaren barruan nola begiratu behar duen nahiak daude. Esate baterako, benetan nahi genuen kableak sorta batean konbinatu eta tira, dentsitate handiko adabaki-panel bat guztiz adabaki-panel batean sartu zedin, luzerari dagokionez zoorik ez egon zedin. Arazo hau konpontzea lortu dugu. Hasieran topologia logikoari erreparatuz gero, planoak independenteak direla ikus daiteke, plano bakoitza bere kabuz eraiki daiteke. Baina horrelako sorta bat gehitzen dugunean eta adabaki-panel osoa adabaki-panel batera arrastatu nahi dugunean, plano desberdinak nahastu behar ditugu sorta baten barruan eta tarteko egitura bat sartu gurutze-konexio optikoen moduan, muntatu ziren modutik berriro paketatzeko. segmentu batean, beste segmentu batean nola bilduko diren. Horri esker, ezaugarri polit bat lortzen dugu: aldakuntza konplexu guztia ez da bastidoreetatik haratago doa. Zerbait oso indartsu lotu behar duzunean, "hegazkinak zabaldu", batzuetan Clos sareetan deitzen den bezala, dena rack baten barruan kontzentratzen da. Ez dugu oso desmuntatu, banakako estekak, rack batetik bestera aldatzeko.
Horrela ikusten da kable azpiegituraren antolaketa logikoaren ikuspuntutik. Ezkerreko irudian, kolore anitzeko blokeek lehen mailako bizkarrezurreko etengailuen blokeak irudikatzen dituzte, zortzi pieza bakoitza eta haietatik datozen lau kable-sorta, bizkarrezurreko 2 etengailuen blokeetatik datozen sortekin gurutzatzen direnak. .
Lauki txikiek elkarguneak adierazten dituzte. Goiko ezkerrean halako elkargune bakoitzaren matxura dago, hau benetan 512 by 512 portuko gurutze-konexioaren modulua da, kableak berriro paketatzen dituena rack batean sartu daitezen, non bizkarrezurra-2 plano bakarra dagoen. Eskuinean, argazki honen eskaneatzea apur bat zehatzagoa da bizkarrezurra-1 mailan dauden Pods-ekin lotuta, eta nola gurutzatu-konexio batean ontziratzen den, nola bizkarrezurra-2 mailara iristen den.
Honela dirudi. Oraindik guztiz muntatu ez den bizkarrezurra-2 zutabea (ezkerrean) eta gurutze-konexioa. Zoritxarrez, ez dago asko ikusteko. Egitura osoa zabaltzen ari da oraintxe zabaltzen ari diren gure datu-zentro handietako batean. Hau abian dagoen lana da, itxura politagoa izango da, hobeto beteko da.
Galdera garrantzitsu bat: topologia logikoa aukeratu eta fisika eraiki genuen. Zer gertatuko da kontrol-hegazkinarekin? Operazio-esperientziagatik nahiko ezaguna da, egoera-protokoloak onak direla dioten txosten batzuk daude, plazer bat da haiekin lan egitea, baina, tamalez, ez dira ondo eskalatzen trinkoki konektatutako topologia batean. Eta hori eragozten duen faktore nagusi bat dago: hau da uholdeak nola funtzionatzen duen esteken egoera protokoloetan. Uholde-algoritmoa hartu eta gure sarea nola egituratzen den ikusten baduzu, urrats bakoitzean oso fanout handia egongo dela ikusiko duzu, eta kontrol-hegazkina eguneratzeekin gainezka egingo duela. Zehazki, topologiak oso gaizki nahasten dira lotura-egoeraren protokoloetako uholde-algoritmo tradizionalarekin.
Aukera BGP erabiltzea da. Nola prestatu behar bezala RFC 7938-n deskribatzen da BGP datu-zentro handietan erabiltzeari buruz. Oinarrizko ideiak sinpleak dira: ostalari bakoitzeko gutxieneko aurrizki-kopurua eta orokorrean gutxieneko aurrizki-kopurua sarean, ahal bada agregazioa erabili eta bide-ehiza kendu. Eguneratzeen banaketa oso zaindua, oso kontrolatua nahi dugu, bailara librea deitzen dena. Eguneratzeak saretik igarotzen diren heinean behin zehatz-mehatz zabaltzea nahi dugu. Behean jatorria badute, gora doaz, behin baino gehiagotan zabalduz. Ez da sigi-sagarik egon behar. Sigi-sagak oso txarrak dira.
Horretarako, azpian dauden BGP mekanismoak erabiltzeko nahikoa sinplea den diseinua erabiltzen dugu. Hau da, link lokalean exekutatzen den eBGP erabiltzen dugu, eta sistema autonomoak honela esleitzen dira: sistema autonomo bat ToR-en, sistema autonomo bat Pod baten bizkarrezurra-1 etengailuen bloke osoan eta sistema autonomo orokor bat Goi osoan. Oihalarena. Ez da zaila BGPren portaera normalak ere nahi ditugun eguneraketen banaketa ematen digula ikustea eta ikustea.
Berez, helbideratze- eta helbide-agregazioa diseinatu behar da bideratze-moduarekin bateragarria izan dadin, kontrol-planoaren egonkortasuna bermatzeko. Garraioan L3 helbideratzea topologiari lotuta dago, hori gabe ezinezkoa baita agregazioa lortzea; hori gabe, helbide indibidualak bideratze sistemara sartuko dira. Eta beste gauza bat da agregazioa, zoritxarrez, ez dela oso ondo nahasten bide anitzekoarekin, izan ere, bide anitzekoa dugunean eta agregazioa dugunean dena ondo dago, sare osoa osasuntsu dagoenean ez dago hutsegiterik. Zoritxarrez, sarean akatsak agertu eta topologiaren simetria galdu bezain laster, unitatea iragarri zen puntura iritsi gaitezke, eta hortik ezin gara joan behar dugun tokira urrunago joan. Hori dela eta, bide anitzeko bide gehiagorik ez dagoen tokian gehitzea da onena, gure kasuan ToR etengailuak dira.
Izan ere, batzea posible da, baina kontu handiz. Sareko akatsak gertatzen direnean desagregazio kontrolatua egin ahal badugu. Baina nahiko lan zaila da, hau egitea posible ote zen galdetu genuen, automatizazio gehigarria gehitzea posible ote zen eta BGP behar bezala jaurtiko luketen egoera finituko makinak nahi den portaera lortzeko. Zoritxarrez, txokoen kasuak prozesatzea oso ez da agerikoa eta konplexua, eta zeregin hori ez da ondo konpontzen BGPra kanpoko eranskinak erantsiz.
Ildo horretan oso lan interesgarria egin da RIFT protokoloaren esparruan, hurrengo txostenean aztertuko dena.
Beste gauza garrantzitsu bat da datu-planoak nola eskalatzen dituen topologia trinkoetan, non bide alternatibo ugari ditugun. Kasu honetan, hainbat datu-egitura gehigarri erabiltzen dira: ECMP taldeak, hauek, aldi berean, Next Hop taldeak deskribatzen dituztenak.
Normalki funtzionatzen duen sare batean, hutsegiterik gabe, Clos topologian gora egiten dugunean, nahikoa da talde bakarra erabiltzea, lokala ez den guztia lehenespenez deskribatzen baita, gora egin dezakegu. Goitik behera hegoaldera goazenean, orduan bide guztiak ez dira ECMP, bide bakarreko bideak dira. Dena ondo dago. Arazoa da, eta Clos topologia klasikoaren berezitasuna, ehunaren Goialdeari begiratzen badiogu, edozein elementuri, azpian dagoen edozein elementurako bide bakarra dagoela. Bide horretan akatsak gertatzen badira, lantegiaren goiko aldean dagoen elementu jakin hau baliogabea bihurtzen da, hain zuzen, hautsitako bidearen atzean dauden aurrizki horietarako. Baina gainerakoan balio du, eta ECMP taldeak aztertu eta egoera berri bat aurkeztu behar dugu.
Nolakoa da datu-planoaren eskalagarritasuna gailu modernoetan? LPM (aurrizkiaren parekorik luzeena) egiten badugu, dena nahiko ona da, 100k aurrizki baino gehiago. Next Hop taldeez ari bagara, dena okerragoa da, 2-4 mila. Next Hops-en (edo albokotasunen) deskribapena duen taula bati buruz ari bagara, 16k-tik 64k-ra bitartekoa da. Eta hau arazo bihur daiteke. Eta hemen digresio interesgarri batera iritsiko gara: zer gertatu da MPLSrekin datu-zentroetan? Printzipioz, egin nahi genuen.
Bi gauza gertatu ziren. Ostalarietan mikrosegmentazioa egin genuen; jada ez genuen sarean egin behar. Ez zen oso ona saltzaile ezberdinen laguntzarekin, eta are gehiago MPLS-rekin kutxa zurietan inplementazio irekiekin. Eta MPLS, bere inplementazio tradizionalak behintzat, zoritxarrez, oso gaizki konbinatzen du ECMPrekin. Eta horregatik.
Hau da IPrako ECMP birbidaltze-egituraren itxura. Aurrizki kopuru handi batek talde bera eta Next Hops bloke bera erabil ditzake (edo aldamenak, gailu desberdinetarako dokumentazio ezberdinetan dei daiteke hori). Kontua da irteerako ataka gisa deskribatzen dela eta MAC helbidea zertara berridatzi behar den Next Hop zuzenera iristeko. IPrako dena sinplea dirudi, talde bererako aurrizki kopuru oso handia erabil dezakezu, Next Hops bloke bera.
MPLS arkitektura klasikoak esan nahi du, irteerako interfazearen arabera, etiketa balio ezberdinekin berridatzi daitekeela. Horregatik, talde bat eta Next Hops bloke bat mantendu behar ditugu sarrera-etiketa bakoitzeko. Eta hau, ai, ez da eskalatzen.
Erraza da gure diseinuan 4000 ToR etengailu inguru behar genituela, gehienezko zabalera 64 ECMP bidekoa zen, bizkarrezurra-1etik urruntzen bagara bizkarrezurra-2rantz. Ozta-ozta sartzen gara ECMP taldeen taula batean, ToR duen aurrizki bakarra desagertzen bada, eta ez bagara batere Next Hops taulan sartzen.
Dena ez dago itxaropenik gabe, Segment Routing bezalako arkitekturak etiketa globalak baitituzte. Formalki, posible izango litzateke Next Hops bloke horiek guztiak berriro kolapsatzea. Horretarako, komodin motako eragiketa bat behar duzu: hartu etiketa eta berridatzi balio zehatzik gabe berdinean. Baina, zoritxarrez, hori ez dago oso presente eskuragarri dauden inplementazioetan.
Eta azkenik, kanpoko trafikoa datu-zentrora eraman behar dugu. Nola egin? Aurretik, trafikoa Clos sarean goitik sartzen zen. Hau da, ehunaren Goiko gailu guztietara konektatzen ziren ertz-bideratzaileak zeuden. Soluzio honek nahiko ondo funtzionatzen du tamaina txiki eta ertainetan. Zoritxarrez, modu honetan trafikoa sare osora simetrikoki bidaltzeko, aldi berean iritsi behar dugu oihalaren Goiko elementu guztietara, eta ehunetik gora daudenean, handi bat ere behar dugula gertatzen da. radix ertzeko bideratzaileetan. Orokorrean, horrek dirua kostatzen du, ertzeko bideratzaileak funtzionalagoak direlako, horien portuak garestiagoak izango direlako eta diseinua ez da oso ederra.
Beste aukera bat trafiko hori behetik hastea da. Erraza da egiaztatzea Clos topologia behetik datorren trafikoa, hau da, ToR aldetik datorrena, ehunaren Goialde osoan zehar mailetan uniformeki banatzen dela bi iteraziotan, sare osoa kargatuz. Horregatik, Edge Pod mota berezi bat aurkezten dugu, kanpoko konexioa eskaintzen duena.
Aukera bat gehiago dago. Hori da Facebookek egiten duena, adibidez. Fabric Aggregator edo HGRID deitzen diote. Bizkarrezurreko maila gehigarri bat sartzen ari da hainbat datu-zentro konektatzeko. Diseinu hau posible da interfazeetan funtzio gehigarririk edo kapsulatze-aldaketarik ez badugu. Ukipen puntu gehigarriak badira, zaila da. Normalean, datu-zentroaren zati desberdinak bereizten dituen funtzio gehiago eta mintz moduko bat daude. Ez du ezertarako mintza hori handi egiteak, baina arrazoiren batengatik benetan beharrezkoa bada, zentzuzkoa da kentzeko aukera kontuan hartzea, ahalik eta zabalena egin eta ostalariengana eramatea. Hori, adibidez, hodeiko operadore askok egiten dute. Gainjartzeak dituzte, ostalarietatik abiatzen dira.
Zein garapen aukera ikusten ditugu? Lehenik eta behin, CI/CD kanalizaziorako euskarria hobetzea. Probatzen eta probatzen dugun moduan hegan egin nahi dugu. Horrek ez du oso ondo funtzionatzen, azpiegitura handia delako eta ezinezkoa delako bikoiztu probak egiteko. Ulertu behar duzu nola sartu probako elementuak ekoizpen-azpiegituran erori gabe.
Tresneria hobea eta monitorizazio hobea ez dira ia inoiz soberan geratzen. Galdera osoa esfortzuaren eta itzuleraren oreka da. Arrazoizko ahaleginarekin gehitzen baduzu, oso ondo.
Sistema eragile irekiak sareko gailuetarako. Protokolo hobeak eta bideratze sistema hobeak, hala nola RIFT. Pilaketak kontrolatzeko eskema hobeak erabiltzeari buruzko ikerketa ere egin behar da eta agian, puntu batzuetan behintzat, RDMA laguntza kluster barruan sartzea.
Etorkizunera begira, topologia aurreratuak eta beharbada gainkostu gutxiago erabiltzen dituzten sareak behar ditugu. Gauza freskoen artean, duela gutxi HPC Cray Slingshot-en ehunaren teknologiari buruzko argitalpenak egin dira, hau da, Ethernet merkantzian oinarritzen dena, baina goiburu askoz laburragoak erabiltzeko aukerarekin. Ondorioz, gainkostuak murrizten dira.
Dena ahalik eta sinpleena izan behar da, baina ez sinpleagoa. Konplexutasuna eskalagarritasunaren etsaia da. Sinpletasuna eta egitura erregularrak dira gure lagunak. Nonbait eskalatzen baduzu, egin ezazu. Eta, oro har, oso ona da orain sareko teknologietan parte hartzea. Gauza interesgarri asko gertatzen ari dira. Eskerrik asko.
Iturria: www.habr.com