Datu-zentro modernoek ehunka gailu aktibo instalatuta dituzte, monitorizazio mota ezberdinek estalita. Baina monitorizazio perfektua eskuan duen ingeniari ideal batek ere sareko hutsegite bati minutu gutxiren buruan erantzun ahal izango dio. Next Hop 2020 konferentzian egindako txosten batean, DC sarearen diseinuaren metodologia aurkeztu nuen, ezaugarri berezi bat duena: datu-zentroa milisegundotan sendatzen da. Zehatzago esanda, ingeniariak lasaitasunez konpontzen du arazoa, zerbitzuek besterik gabe nabaritzen ez duten bitartean.
Sareko ingeniari askorentzat, datu-zentroen sarea hasten da, noski, ToRrekin, rack-en etengailu batekin. ToR-k normalean bi esteka mota ditu. Txikiak zerbitzarietara joaten dira, beste batzuk -N aldiz gehiago dira- lehen mailako bizkarrezurretara doaz, hau da, bere gorako esteketara. Goranzko estekak normalean berdintzat hartzen dira, eta goranzko esteken arteko trafikoa 5-tuplaren hash batean oinarrituta orekatzen da, hau da, proto, src_ip, dst_ip, src_port, dst_port barne. Hemen ez da sorpresarik.
Ondoren, nolakoa da oinplanoaren arkitektura? Lehen mailako bizkarrezurrak ez daude elkarren artean konektaturik, superspines bidez baizik. X letra superspineen arduraduna izango da; ia gurutze-konexio bat bezalakoa da.
Eta argi dago, bestalde, tori lehen mailako bizkarrezurra guztiekin lotuta daudela. Zer da garrantzitsua irudi honetan? Rack barruan interakzioa badugu, interakzioa, noski, ToR bidez doa. Interakzioa modulu barruan gertatzen bada, orduan elkarrekintza lehen mailako bizkarrezurra bidez gertatzen da. Elkarreragina intermodularra bada - hemen bezala, ToR 1 eta ToR 2 - orduan elkarrekintza lehenengo eta bigarren mailako bizkarrezurra igaroko da.
Teorian, horrelako arkitektura bat erraz eskalagarria da. Portu-ahalmena, datu-zentroan ordezko lekua eta aurrez jarritako zuntza baditugu, errei-kopurua beti handitu daiteke, horrela sistemaren ahalmen orokorra handituz. Hau oso erraza da paperean egitea. Horrela izango litzateke bizitzan. Baina gaurko istorioa ez da horren ingurukoa.
Ondorio egokiak ateratzea nahi dut. Datu-zentroaren barruan bide asko ditugu. Baldintzaz independenteak dira. Datu-zentroaren barruko bide bat ToR barruan bakarrik da posible. Moduluaren barruan, bide kopurua errei kopuruaren berdina dugu. Moduluen arteko bide-kopurua plano bakoitzeko planoen eta superespine-kopuruaren biderkaduraren berdina da. Argiago uzteko, eskalaren zentzua izateko, Yandex datu-zentroetako baterako balio duten zenbakiak emango ditut.
Zortzi hegazkin daude, hegazkin bakoitzak 32 superespine ditu. Ondorioz, moduluaren barruan zortzi bide daude, eta moduluen arteko elkarrekintzarekin dagoeneko 256 daude.
Hau da, Cookbook garatzen ari bagara, bere burua sendatzen duten akatsekiko tolerantzia duten datu-zentroak nola eraikitzen ikasten saiatzen ari bagara, orduan arkitektura planarra aukera egokia da. Eskalatzeko arazoa konpontzen du, eta teorian erraza da. Bide independente asko daude. Galdera geratzen da: nola irauten du horrelako arkitektura batek porrotetatik? Hainbat porrot daude. Eta honetaz eztabaidatuko dugu orain.
Utzi gure superspineetako bat "gaixotu". Hemen bi planoko arkitekturara itzuli nintzen. Hauekin jarraituko dugu adibide gisa, zati mugikor gutxiagorekin zer gertatzen den ikustea errazagoa izango delako. Ea X11 gaixotu. Nola eragingo die horrek datu-zentroen barruan bizi diren zerbitzuei? Asko da hutsegitearen itxuraren araberakoa.
Porrota ona bada, BFD beraren automatizazio mailan harrapatzen da, automatizazioak zorionez juntura problematikoak jartzen ditu eta arazoa isolatzen du, orduan dena ondo dago. Bide asko ditugu, trafikoa berehala bideratzen da bide alternatiboetara, eta zerbitzuek ez dute ezer nabarituko. Hau gidoi ona da.
Eszenatoki txarra da etengabeko galerak baditugu, eta automatizazioak arazoa nabaritzen ez badu. Honek aplikazio bati nola eragiten dion ulertzeko, denbora pixka bat eman beharko dugu TCP nola funtzionatzen duen eztabaidatzen.
Espero dut informazio honekin inor ez harritzea: TCP transmisioa berresteko protokoloa da. Hau da, kasurik errazenean, igorleak bi pakete bidaltzen ditu eta horien gainean ack metatu bat jasotzen du: "Bi pakete jaso ditut".
Horren ostean, beste bi pakete bidaliko ditu, eta egoera errepikatuko da. Barkamena eskatzen dut aldez aurretik sinplifikazioengatik. Egoera hau zuzena da leihoa (hegaldian dauden pakete kopurua) bi bada. Jakina, kasu orokorrean hori ez da zertan hala gertatzen. Baina leihoaren tamainak ez du paketeen birbidaltze testuinguruan eragiten.
Zer gertatzen da 3. paketea galtzen badugu? Kasu honetan, hartzaileak 1., 2. eta 4. paketeak jasoko ditu. Eta espresuki esango dio igorleari SACK aukera erabiliz: βBadakizu, hiru iritsi dira, baina erdia galdu daβ. Berak dio: "Ack 2, SACK 4".
Momentu honetan, igorleak arazorik gabe galdutako paketea zehatz-mehatz errepikatzen du.
Baina leihoko azken paketea galtzen bada, egoera guztiz bestelakoa izango da.
Hartzaileak lehenengo hiru paketeak jasotzen ditu eta lehenik itxaroten hasten da. Linux kernelaren TCP pilako optimizazio batzuei esker, parekatutako pakete baten zain egongo da, banderak esplizituki azken paketea edo antzeko zerbait dela adierazten ez badu behintzat. Atzeratutako ACK denbora-muga agortu arte itxarongo da eta gero aitorpena bidaliko du lehen hiru paketeetan. Baina orain igorleak itxarongo du. Ez daki laugarren paketea galdu den edo iristear dagoen. Eta sarea gainkargatu ez dadin, paketea galduta dagoela adierazten duen adierazgarri esplizitu baten zain edo RTO denbora-muga iraungi arte itxaroten saiatuko da.
Zer da RTO denbora-muga? Hau da TCP pilak eta konstante batzuk kalkulatutako RTT-ren maximoa. Nolako konstantea den hau, orain eztabaidatuko dugu.
Baina garrantzitsuena da berriro zorte txarra badugu eta laugarren paketea berriro galtzen bada, RTO bikoiztu egiten dela. Hau da, arrakastarik gabeko saiakera bakoitzak denbora-muga bikoiztu egiten du.
Orain ikus dezagun zer den oinarri hau. Lehenespenez, gutxieneko RTO 200 ms-koa da. Hau da datu-paketeetarako gutxieneko RTOa. SYN paketeetarako desberdina da, segundo 1. Ikus dezakezunez, paketeak berriro bidaltzeko lehen saiakerak ere datu-zentroaren barruan RTT baino 100 aldiz gehiago beharko du.
Orain itzul gaitezen gure eszenatokira. Zer gertatzen da zerbitzuarekin? Zerbitzua paketeak galtzen hasten da. Zerbitzuari zortea baldintzapean izan dezala hasieran eta leihoaren erdian zerbait galtzen du, gero ZAKO bat jasoko du eta galdutako paketeak berriro bidaltzen ditu.
Baina zorte txarra errepikatzen bada, orduan RTO bat dugu. Zer da garrantzitsua hemen? Bai, gure sarean bide asko ditugu. Baina TCP konexio jakin baten TCP trafikoak hautsitako pila beretik jarraituko du. Pakete-galerak, baldin eta gure X11 magiko hau bere kabuz irteten ez bada, ez du trafikoa arazotsuak ez diren guneetara iristen. Paketea hautsitako pila beraren bidez bidaltzen saiatzen ari gara. Horrek kaskadako hutsegite bat dakar: datu-zentro bat elkarreraginean dauden aplikazio multzo bat da, eta aplikazio horien guztien TCP konexio batzuk degradatzen hasten dira - superspine-k datu-zentroaren barruan dauden aplikazio guztiei eragiten dielako. Esaerak dioen bezala: ez bazenu zaldia ferratu, zaldia herren egiten zen; zaldia herren joan zen - txostena ez zen eman; txostena ez zen entregatu - gerra galdu genuen. Hemen bakarrik kontua segundotan dago arazoa sortzen den unetik zerbitzuek sentitzen hasten diren degradazio faseraino. Horrek esan nahi du erabiltzaileek zerbait galdu dezaketela nonbait.
Elkarren osagarri diren bi irtenbide klasiko daude. Lehenengoa lastoak jarri eta arazoa honela konpontzen saiatzen ari diren zerbitzuak dira: βTCP pilan zerbait moldatu dezagun. Egin ditzagun denbora-mugak aplikazio mailan edo iraupen luzeko TCP saioetan barne osasun-egiaztapenekin". Arazoa da horrelako irtenbideak: a) ez direla batere eskalatzen; b) oso gaizki egiaztatuta daude. Hau da, zerbitzuak ustekabean TCP pila hobetzen duen moduan konfiguratzen badu ere, lehenik eta behin, nekez aplikatuko da aplikazio guztietan eta datu-zentro guztietan, eta bigarrenik, ziurrenik, ez du ulertuko egin zenik. zuzen, eta zer ez. Hau da, funtzionatzen du, baina gaizki funtzionatzen du eta ez du eskalatzen. Eta sare arazoren bat badago, noren errua? Jakina, NOC. Zer egiten du NOCek?
Zerbitzu askok uste dute NOCen lana horrelako zerbait gertatzen dela. Baina egia esateko, ez hori bakarrik.
NOC eskema klasikoan monitorizazio sistema asko garatzen ari da. Hauek kutxa beltza eta kutxa zuriaren jarraipena dira. Kutxa beltzaren bizkarrezurreko monitorizazioaren adibide bati buruz Alexander Klimenko azken Next Hop-en. Bide batez, jarraipen honek funtzionatzen du. Baina monitorizazio idealak ere denbora atzerapena izango du. Normalean minutu batzuk izaten dira. Itzali ondoren, lanean ari diren ingeniariek denbora behar dute funtzionamendua egiaztatzeko, arazoa lokalizatzeko eta, ondoren, arazo-eremua itzaltzeko. Hau da, kasurik onenean, arazoa tratatzeak 5 minutu behar ditu, kasurik txarrenean, 20 minutu, galerak non gertatzen diren berehala nabaritzen ez bada. Argi dago denbora guzti honetan - 5 edo 20 minutu - gure zerbitzuek jasaten jarraituko dutela, eta hori seguruenik ez da ona.
Zer jaso nahiko zenuke benetan? Modu asko ditugu. Eta arazoak sortzen dira, hain zuzen, zorte txarra duten TCP fluxuek bide bera erabiltzen jarraitzen dutelako. TCP konexio bakarrean hainbat ibilbide erabiltzeko aukera emango digun zerbait behar dugu. Badirudi irtenbidea dugula. TCP dago, bide anitzeko TCP deritzona, hau da, bide anitzeko TCP. Egia da, guztiz bestelako zeregin baterako garatu zen - sareko hainbat gailu dituzten telefono adimendunetarako. Transferentzia maximizatzeko edo lehen/backup modua egiteko, mekanismo bat garatu zen, aplikaziorako hari (saio) anitz sortzen dituena gardentasunez eta hutsegiterik gertatuz gero haien artean aldatzeko aukera ematen duena. Edo, esan bezala, marra maximizatu.
Baina Γ±abardura bat dago hemen. Zer den ulertzeko, hariak nola ezartzen diren aztertu beharko dugu.
Hariak sekuentzialki instalatzen dira. Lehenengo haria instalatzen da lehenik. Ondoren, hari horren barruan adostu den cookiea erabiliz ezartzen dira ondorengo hariak. Eta hona hemen arazoa.
Arazoa da lehen haria bere burua ezartzen ez bada, bigarren eta hirugarren hariak ez direla inoiz sortuko. Hau da, bide anitzeko TCPk ez du lehen fluxuan SYN pakete baten galera konpontzen. Eta SYN galtzen bada, bide anitzeko TCP TCP arrunt bihurtzen da. Horrek esan nahi du datu-zentroko ingurune batean ez gaituela lagunduko fabrikako galeren arazoa konpontzen eta hutsegite bat gertatuz gero hainbat bide erabiltzen ikasiko.
Zertan lagun gaitzake? Zuetako batzuk dagoeneko asmatu duzue izenburutik gure istorioko eremu garrantzitsu bat IPv6 fluxuaren etiketa goiburuko eremua izango dela. Izan ere, v6-n agertzen den eremu bat da, ez dago v4-n, 20 bit hartzen ditu eta erabileraren inguruan eztabaida sortu da denbora luzez. Hau oso interesgarria da: gatazkak egon ziren, RFC barruan zerbait konpondu zen eta, aldi berean, Linux nukleoan inplementazio bat agertu zen, inon dokumentatuta ez zegoena.
Nirekin ikerketa txiki bat egitera gonbidatzen zaitut. Ikus dezagun azken urteotan Linux nukleoan gertatzen ari dena.
2014 urtea. Enpresa handi eta errespetatu bateko ingeniari batek Linux kernelaren funtzionaltasunari socket hash-aren fluxu etiketaren balioaren menpekotasuna gehitzen dio. Zer konpontzen saiatzen ziren hemen? Hau RFC 6438rekin erlazionatuta dago, zeinak hurrengo gaia eztabaidatu zuen. Datu zentroaren barruan, sarritan IPv4 IPv6 paketeetan kapsulatzen da, fabrika bera IPv6 delako, baina IPv4 kanpoan eman behar da nolabait. Denbora luzez arazoak izan ziren TCP edo UDPra iristeko bi IP goibururen azpian begiratu eta bertan src_ports, dst_ports aurkitzeko ezin zuten etengailuekin. Hash-a, lehen bi IP goiburuei erreparatuz gero, ia konponduta zegoela ikusi zen. Hori ekiditeko, kapsulatutako trafiko honen orekatzeak behar bezala funtziona dezan, 5-tupla kapsulatutako paketearen hash-a gehitzea proposatu zen fluxuaren etiketa eremuaren balioari. Gutxi gorabehera gauza bera egin zen beste kapsulatze eskemetarako, UDPrako, GRErako, azken honek GRE Key eremua erabili zuen. Nola edo hala, hemen helburuak argiak dira. Eta momentu horretan behintzat baliagarriak ziren.
2015ean, ingeniari errespetatu beraren adabaki berri bat dator. Oso interesgarria da. Honako hau dio: hash-a ausaz banatuko dugu bideratze-gertaera negatiboa izanez gero. Zer da bideratze-gertaera negatiboa? Hau da lehen aipatu dugun RTO, hau da, leihoaren buztana galtzea benetan negatiboa den gertaera bat da. Egia da, nahiko zaila da hori dela asmatzea.
2016, beste enpresa entzutetsu bat, handia ere. Azken makuluak desmuntatzen ditu eta lehen ausaz egiten genuen hash-a orain SYN birtransmisio bakoitzeko eta RTO denbora-muga bakoitzaren ondoren aldatzen da. Eta gutun honetan, lehen eta azkenekoz, azken helburua adierazten da: galerak edo kanalen pilaketak gertatuz gero trafikoak emeki birbideratzeko eta bide anitz erabiltzeko gaitasuna duela ziurtatzea. Noski, honen ondoren argitalpen asko zeuden, erraz aurki ditzakezu.
Ezetz arren, ezin duzu, gai honi buruzko argitalpen bakar bat ere ez baita egon. Baina badakigu!
Eta egindakoa guztiz ulertzen ez baduzu, orain esango dizut.
Zer egin zen, zein funtzionalitate gehitu zitzaion Linux nukleoari? xhash ausazko balio batera aldatzen da RTO gertaera bakoitzaren ondoren. Hau bideratzearen emaitza oso negatiboa da. Hash-a txhash honen araberakoa da, eta fluxuaren etiketa skb hash-aren araberakoa da. Funtzioei buruzko kalkulu batzuk daude hemen; xehetasun guztiak ezin dira diapositiba batean jarri. Norbaitek jakin-mina badu, nukleoaren kodea pasa eta egiaztatu dezakezu.
Zer da garrantzitsua hemen? Fluxuaren etiketa eremuaren balioa ausazko zenbaki batera aldatzen da RTO bakoitzaren ondoren. Nola eragiten dio horrek gure zorigaiztoko TCP korronteari?
SACK bat gertatzen bada, ez da ezer aldatzen galdutako pakete ezagun bat berriro bidaltzen saiatzen ari garelako. Orain arte ondo.
Baina RTOren kasuan, baldin eta ToR-en hash funtzioari fluxu etiketa bat gehitu badiogu, trafikoak beste bide bat har dezake. Eta zenbat eta errei gehiago, orduan eta aukera handiagoa izango du gailu jakin batean hutsegite batek eragiten ez duen bide bat aurkitzeko.
Arazo bat geratzen da - RTO. Noski, badago beste ibilbide bat, baina denbora asko galtzen da honetan. 200 ms asko da. Bigarren bat erabat basatia da. Aurretik, zerbitzuak konfiguratuta dauden denbora-mugei buruz hitz egin nuen. Beraz, bigarren bat denbora-muga bat da, normalean zerbitzuak aplikazio mailan konfiguratzen duena, eta honetan zerbitzua nahiko egokia izango da. Gainera, errepikatzen dut, benetako RTT datu-zentro moderno baten barruan milisegundo 1 ingurukoa da.
Zer egin dezakezu RTO denbora-mugekin? Denbora-muga, datu-paketeen galeraren kasuan RTOren arduraduna dena, nahiko erraz konfigura daiteke erabiltzailearen espaziotik: IP utilitate bat dago, eta bere parametroetako batek rto_min bera dauka. Kontuan izanik, noski, RTO ez globalki egokitu behar dela, baizik eta emandako aurrizkietarako, mekanismo horrek nahiko funtzionagarria dirudi.
Egia da, SYN_RTO-rekin dena okerragoa da. Berez iltzatuta dago. Nukleoak 1 segundoko balio finkoa du, eta kitto. Ezin zara bertara iritsi erabiltzailearen espaziotik. Modu bakarra dago.
eBPF erreskatatzera dator. Erraz esateko, C programa txikiak dira. Nukleoaren pilaren eta TCP pilaren exekuzioan hainbat tokitan kakoetan txerta daitezke, eta horrekin ezarpen kopuru handia alda dezakezu. Oro har, eBPF epe luzerako joera da. Dozenaka sysctl parametro berri moztu eta IP utilitatea zabaldu beharrean, mugimendua eBPFrantz doa eta bere funtzionaltasuna zabaltzen ari da. eBPF erabiliz, pilaketa kontrolak eta beste TCP ezarpen desberdinak modu dinamikoan alda ditzakezu.
Baina guretzat garrantzitsua da SYN_RTO balioak aldatzeko erabil daitekeela. Gainera, publikoki argitaratutako adibide bat dago: . Zer egin da hemen? Adibidea funtzionatzen ari da, baina berez oso latza da. Hemen suposatzen da datu-zentroaren barruan lehenengo 44 bitak alderatzen ditugula; bat badatoz, datu-zentroaren barruan gaude. Eta kasu honetan SYN_RTO denbora-muga balioa 4 ms-ra aldatzen dugu. Zeregin bera askoz dotoreago egin daiteke. Baina adibide sinple honek hau a) posible dela erakusten du; b) nahiko sinplea.
Zer dakigu dagoeneko? Plano-arkitekturak eskalatzea ahalbidetzen duelako, oso baliagarria iruditzen zaigu ToR-en fluxu-etiketa gaitzen dugunean eta arazo-eremuen inguruan isurtzeko gaitasuna lortzen dugunean. RTO eta SYN-RTO balioak murrizteko modurik onena eBPF programak erabiltzea da. Galdera geratzen da: segurua al da fluxu-etiketa erabiltzea orekatzeko? Eta Γ±abardura bat dago hemen.
Demagun zure sarean anycast-en bizi den zerbitzu bat duzula. Zoritxarrez, ez dut astirik zer den anycast zer den zehatz-mehatz sartzeko, baina IP helbide beraren bidez eskura daitezkeen zerbitzari fisiko desberdinak dituen zerbitzu banatua da. Eta hona hemen arazo posible bat: RTO gertaera gerta daiteke trafikoa ehunetik igarotzean ez ezik. ToR buffer mailan ere gerta daiteke: incast-eko gertaera bat gertatzen denean, ostalariarengan ere gerta daiteke ostalariak zerbait isurtzen duenean. RTO gertaera bat gertatzen denean eta fluxuaren etiketa aldatzen duenean. Kasu honetan, trafikoa beste anycast instantzia batera joan daiteke. Demagun egoera hau anycast bat dela, konexio-egoera bat dauka - L3 Balancer bat edo beste zerbitzuren bat izan daiteke. Orduan arazo bat sortzen da, RTOren ondoren TCP konexioa zerbitzarira iristen delako, eta horrek ez daki ezer TCP konexio honi buruz. Eta anycast zerbitzarien artean egoera partekatzea ez badugu, trafiko hori kendu egingo da eta TCP konexioa hautsiko da.
Zer egin dezakezu hemen? Zure ingurune kontrolatuan, non fluxu etiketen oreka gaitzen duzun, fluxuaren etiketaren balioa erregistratu behar duzu anycast zerbitzarietara sartzean. Modurik errazena eBPF programa beraren bidez egitea da. Baina hona hemen oso puntu garrantzitsu bat: zer egin datu-zentroko sare bat erabiltzen ez baduzu, baina telekomunikazio-operadore bat bazara? Hau ere zure arazoa da: Juniper eta Aristaren bertsio jakin batzuetatik hasita, fluxu etiketa bat sartzen dute beren hash funtzioetan lehenespenez - egia esan, argi ez dudan arrazoi batengatik. Horrek zure saretik pasatzen diren erabiltzaileen TCP konexioak kentzea eragin dezake. Beraz, zure bideratzaileen ezarpenak hemen egiaztatzea gomendatzen dut.
Nola edo hala, esperimentuetara pasatzeko prest gaudela iruditzen zait.
ToR-en fluxuaren etiketa gaitu genuenean, eBPF agentea prestatu genuenean, orain ostalarietan bizi dena, hurrengo hutsegite handira ez itxarotea erabaki genuen, leherketa kontrolatuak egitea baizik. ToR hartu genuen, lau esteka dituena, eta horietako batean deskargak ezarri genituen. Arau bat marraztu zuten eta esan zuten: orain pakete guztiak galtzen ari zara. Ezkerrean ikusten denez, pakete bakoitzeko jarraipena dugu, %75era jaitsi da, hau da, paketeen %25 galtzen dira. Eskuinean ToR honen atzean bizi diren zerbitzuen grafikoak daude. Funtsean, rack barruan zerbitzariak dituzten interfazeen trafiko grafikoak dira. Ikusten duzunez, are beherago hondoratu ziren. Zergatik jaitsi dira beherago - ez % 25, ββbaina kasu batzuetan 3-4 aldiz? TCP konexioak zorte txarra badu, hautsitako bidegurutzetik iristen saiatzen jarraitzen du. Hori larriagotu egiten da DC barneko zerbitzuaren portaera tipikoa - erabiltzaile baten eskaerarako, barne zerbitzuetarako N eskaera sortzen dira eta erantzuna erabiltzaileari joango zaio datu-iturri guztiek erantzuten dutenean edo aplikazioan denbora-muga bat gertatzen denean. maila, oraindik konfiguratu behar dena. Hau da, dena oso-oso txarra da.
Orain esperimentu bera, baina fluxuaren etiketaren balioa gaituta. Ikus dezakezunez, ezkerrean gure loteen jarraipena % 25 berean jaitsi zen. Hau guztiz zuzena da, birtransmisioei buruz ezer ez dakielako, paketeak bidaltzen ditu eta entregatu eta galdutako pakete kopuruaren ratioa zenbatzen du.
Eta eskuinaldean zerbitzuen ordutegia. Hemen ez duzu juntura problematiko baten eragina aurkituko. Milisegundo horietan berean, trafikoa arazoaren eremutik arazoaren eraginpean egon ez ziren gainerako hiru esteketara joan zen. Bere burua sendatzen duen sare bat lortu dugu.
Hau da nire azken diapositiba, laburtzeko ordua. Orain, auto-sendatzeko datu-zentroen sare bat eraikitzen jakitea espero dut. Ez duzu Linux nukleoaren artxibotik pasa eta han adabaki berezirik bilatu behar; badakizu kasu honetan Flow etiketak arazoa konpontzen duela, baina mekanismo honi arretaz heldu behar diozu. Eta azpimarratzen dut beste behin telekomunikazio operadorea bazara ez duzula fluxu etiketa erabili behar hash funtzio gisa, bestela zure erabiltzaileen saioak etengo dituzula.
Sareko ingeniariek aldaketa kontzeptual bat jasan behar dute: sarea ez hasten da ToRrekin, ez sareko gailuarekin, ostalariarekin baizik. Adibide nahiko deigarria da eBPF nola erabiltzen dugun bai RTO aldatzeko, bai anycast zerbitzuetarako fluxu etiketa konpontzeko.
Fluxuaren etiketen mekanika kontrolatutako administrazio-segmentuko beste aplikazio batzuetarako egokia da, zalantzarik gabe. Datu-zentroen arteko trafikoa izan daiteke, edo halako mekanika modu berezi batean erabil dezakezu irteerako trafikoa kudeatzeko. Baina hurrengoan esango dizut, espero dut. Mila esker zure arretagatik.
Iturria: www.habr.com