Navendên daneya nûjen bi sedan amûrên çalak hatine saz kirin, ku ji hêla cûrbecûr çavdêriyê ve têne vegirtin. Lê tewra endezyarek îdeal ku di dest de çavdêriya bêkêmasî ye dê tenê di çend hûrdeman de bi rast bersivê bide têkçûna torê. Di raporekê de li konferansa Next Hop 2020, min metodolojiya sêwirana torê ya navenda daneyê pêşkêş kir, ku xwedan taybetmendiyek bêhempa ye - navenda daneyê xwe di millisecond de sax dike. Zêdetir, endezyar bi aramî pirsgirêkê çareser dike, di heman demê de karûbar bi hêsanî wê ferq nakin.
Ji bo gelek endezyarên torê, torgilokek navendek daneyê, bê guman, bi ToR-ê, bi guheztinek di rakê de dest pê dike. ToR bi gelemperî du celeb girêdan hene. Yên piçûk diçin pêşkêşkeran, yên din - N qat ji wan zêdetir in - diçin ber çîpên asta yekem, ango berbi jorînên wê. Girêdan bi gelemperî wekî hev têne hesibandin, û seyrûsefera di navbera lînkan de li ser bingeha hashek ji 5-tuple, ku proto, src_ip, dst_ip, src_port, dst_port vedihewîne, hevseng e. No surprîz li vir.
Piştre, mîmariya planê çawa xuya dike? Pişkên asta yekem bi hev ve ne girêdayî ne, lê bi rêya superspines ve girêdayî ne. Tîpa X dê ji bo superspines berpirsiyar be; ew hema hema mîna girêdanek xaçê ye.
Û eşkere ye ku, ji hêla din ve, tori bi hemî stûnên asta yekem ve girêdayî ne. Di vê wêneyê de çi girîng e? Ger di hundurê rakê de têkiliyek me hebe, wê hingê têkilî, bê guman, bi ToR re derbas dibe. Ger têkiliyek di hundurê modulê de çêbibe, wê hingê pêwendî di nav pêlên asta yekem de pêk tê. Ger danûstendina navmodular be - wekî li vir, ToR 1 û ToR 2 - wê hingê têkilî dê di nav astên yekem û duyemîn de derbas bibe.
Di teoriyê de, mîmariyek weha bi hêsanî mezin dibe. Ger kapasîteya me ya portê, cîhê yedek li navenda daneyê û fîbera pêş-sazkirî hebe, wê hingê her gav hejmara rêkan dikare were zêdekirin, bi vî rengî kapasîteya giştî ya pergalê zêde bike. Ev li ser kaxezê pir hêsan e. Di jiyanê de wê bi vî rengî be. Lê çîroka îro ne li ser vê ye.
Ez dixwazim encamên rast bên derxistin. Di hundurê navenda daneyê de gelek rêyên me hene. Ew bi şert serbixwe ne. Yek rêyek di hundurê navenda daneyê de tenê di hundurê ToR de gengaz e. Di hundurê modulê de, me hejmara rêçikan bi hejmara rêkan re heye. Hejmara rêyên di navbera modulan de bi hilberîna hejmara balafiran û hejmara superspines di her balafirê de wekhev e. Ji bo ku ew zelaltir bikim, ji bo ku têgihîştina pîvanê bigire, ez ê hejmarên ku ji bo yek ji navendên daneya Yandex derbasdar in bidim.
Heşt balafir hene, her balefirek 32 superspine hene. Wekî encamek, derdikeve holê ku heşt rê di hundurê modulê de hene, û bi danûstendina intermodule re jixwe 256 ji wan hene.
Ango, heke em Cookbook pêşve diçin, hewl didin ku fêr bibin ka meriv çawa navendên daneya beredayî yên ku xwe sax dikin ava bikin, wê hingê mîmariya plankirî bijareya rast e. Ew pirsgirêka pîvanê çareser dike, û di teoriyê de ew hêsan e. Gelek rêyên serbixwe hene. Pirs dimîne: mîmariyek weha çawa ji têkçûnan dijî? Têkçûnên cuda hene. Û em ê niha li ser vê yekê nîqaş bikin.
Bila yek ji superspinê me "nexweş bibe". Li vir ez vegeriyam mîmariya du balafiran. Em ê bi van wekî mînakek bisekinin ji ber ku ew ê hêsantir be ku hûn bibînin ka çi diqewime bi hindik beşên tevgerê re. Bila X11 nexweş bibe. Ev ê çawa bandorê li ser karûbarên ku di hundurê navendên daneyê de dijîn bike? Pir tişt girêdayî ye ka têkçûn bi rastî çawa xuya dike.
Ger têkçûn baş be, ew di asta otomatîkî ya heman BFD-ê de tê girtin, otomasyon bi kêfxweşî hevgirêdanên pirsgirêkdar dixe û pirsgirêkê vediqetîne, wê hingê her tişt baş e. Gelek rêyên me hene, seyrûsefer tavilê ji nû ve ber bi rêyên alternatîf ve tê rêve kirin, û karûbar dê tiştek nebînin. Ev senaryoyek baş e.
Senaryoyek xirab ev e ku heke me windahiyên domdar hebin, û otomasyon pirsgirêkê nabîne. Ji bo ku fêm bikin ka ev bandorek çawa li ser serîlêdanê dike, em ê hewce ne ku demek hindik li ser nîqaş bikin ka TCP çawa dixebite.
Ez hêvî dikim ku ez bi vê agahiyê kesek şok nekim: TCP protokolek pejirandina veguhestinê ye. Ango, di rewşa herî hêsan de, şander du pakêtan dişîne û li ser wan akek berhevkirî distîne: "Min du pakêt wergirtin."
Piştî wê, ew ê du pakêtên din bişîne, û rewş dê dubare bibe. Ez di pêş de ji bo hin hêsankirina lêborînê dixwazim. Ger pencereya (hejmara pakêtên di firînê de) du be ev senaryo rast e. Bê guman, di rewşa gelemperî de ev ne hewce ye. Lê mezinahiya pencereyê bandorê li çarçoweya şandina pakêtê nake.
Ger em pakêta 3 winda bikin çi dibe? Di vê rewşê de, wergir dê pakêtên 1, 2 û 4 werbigire. Û ew ê bi vebijarka SACK bi eşkere ji şanderê re bêje: "Hûn dizanin, sê hatin, lê navîn winda bû." Ew dibêje, "Ack 2, SACK 4."
Di vê gavê de şander bêyî pirsgirêk pakêta ku winda bûye dubare dike.
Lê heke pakêta paşîn a paceyê winda bibe, rewş dê bi tevahî cûda xuya bike.
Yê wergir sê pakêtên pêşîn distîne û berî her tiştî dest bi bendkirinê dike. Bi saya hin xweşbîniyên di stûna TCP ya kernel Linux de, ew ê li benda pakêtek hevgirtî bimîne heya ku ala bi eşkere diyar neke ku ew pakêta paşîn an tiştek wusa ye. Ew ê li bendê bimîne heya ku dema Derengmayî ya ACK bi dawî bibe û dûv re li ser sê pakêtên pêşîn pejirandinek bişîne. Lê niha şander dê li bendê bimîne. Ew nizane ka pakêta çaremîn winda bûye an li ber deste. Û ji bo ku torê zêde bar neke, ew ê hewl bide ku li benda nîşanek eşkere ya ku pakêt winda bûye, an ji bo bidawîbûna dema RTO-yê bimîne.
Wextê RTO çi ye? Ev herî zêde ya RTT-ê ye ku ji hêla TCP-ê ve tê hesibandin û hin domdar e. Ev çi cûre berdewam e, em ê niha nîqaş bikin.
Lê ya girîng ev e ku heke em dîsa bêbext bin û pakêta çaremîn dîsa winda bibe, wê hingê RTO du qat dibe. Ango her hewildaneke neserkeftî tê wateya ducarkirina demê.
Niha em bibînin ka ev bingeh bi çi re ye. Bi xwerû, herî kêm RTO 200 ms e. Ev ji bo pakêtên daneyê herî kêm RTO ye. Ji bo pakêtên SYN cuda ye, 1 çirke. Wekî ku hûn dikarin bibînin, tewra yekem hewildana ji nû ve şandina pakêtan jî dê 100 carî ji RTT-ya hundurê navenda daneyê dirêjtir bigire.
Niha em vegerin ser senaryoya xwe. Di xizmetê de çi diqewime? Xizmet dest pê dike ku pakêtan winda bike. Bila karûbar di destpêkê de bi şert bextewar be û tiştek di nîvê pencereyê de winda bike, dûv re ew SACK distîne û pakêtên windabûyî ji nû ve dişîne.
Lê heke şansê xirab xwe dubare bike, wê hingê RTOyek me heye. Li vir çi girîng e? Erê, di tora me de gelek rêyên me hene. Lê seyrûsefera TCP ya yek pêwendiya TCP-ê ya taybetî dê berdewam bike ku di heman stakê şikestî de derbas bibe. Windakirina pakêtê, bi şertê ku ev X11-a meya efsûnî bi serê xwe dernekeve, rê nade ku seyrûsefer diherike deverên ku ne pirsgirêk in. Em hewl didin ku pakêtê bi heman stikê şikestî radest bikin. Ev dibe sedema têkçûnek kaskadî: navendek daneyê komek sepanên pêwenddar e, û hin girêdanên TCP yên van hemî serîlêdanan dest bi hilweşandinê dikin - ji ber ku superspine bandorê li hemî serîlêdanên ku di hundurê navenda daneyê de hene dike. Weke ku tê gotin: eger te hesp neanî, hesp seqet çû; hesp seqet bû - rapor nehat dayîn; rapor nehat dayîn - me şer winda kir. Tenê li vir hejmartin di saniyeyan de ye ji gava ku pirsgirêk derdikeve heya qonaxa hilweşandinê ya ku karûbar dest bi hîskirinê dikin. Ev tê vê wateyê ku dibe ku bikarhêner li cîhek tiştek winda bikin.
Du çareseriyên klasîk hene ku hevûdu temam dikin. Ya yekem karûbar e ku hewil dide ku kavilan têxe hundur û pirsgirêkê bi vî rengî çareser bike: "Werin em tiştek di stoka TCP de bişopînin. Werin em di asta serîlêdanê de an danişînên TCP-yê yên demdirêj bi kontrolên tenduristiya hundurîn re demek dirêj bikin." Pirsgirêk ev e ku çareseriyên weha: a) qet pîvan nakin; b) pir kêm têne kontrol kirin. Ango, her çend karûbar bi xeletî stûna TCP-ê bi rengek ku wê çêtir dike mîheng bike, yekem, ne mimkûn e ku ew ji bo hemî serîlêdan û hemî navendên daneyê were sepandin, û ya duyemîn jî, bi îhtîmalek mezin, ew ê fam neke ku ew hatî çêkirin. rast, û çi ne. Yanî kar dike, lê qels dixebitî û pîvaz nake. Û heger pirsgirêkek torê hebe, kî sûcdar e? Bê guman, NOC. NOC çi dike?
Gelek karûbar bawer dikin ku di xebata NOC de tiştek wusa diqewime. Lê rast be, ne tenê ew.
NOC di pilana klasîk de bi pêşkeftina gelek pergalên çavdêriyê ve mijûl e. Ev hem çavdêriya qutiya reş û hem jî qutiya spî ne. Li ser mînakek çavdêriya spî ya qutiya reş Alexander Klimenko li Hop Next. Bi awayê, ev çavdêrî dixebite. Lê tewra çavdêriya îdeal jî dê demek dereng hebe. Bi gelemperî ev çend hûrdeman e. Piştî ku ew diqewime, endezyarên li ser peywirê pêdivî bi dem heye ku xebata wê ducarî kontrol bikin, pirsgirêkê herêmî bikin û dûv re devera pirsgirêkê vemirînin. Ango, di rewşek çêtirîn de, dermankirina pirsgirêkê 5 hûrdem digire, di rewşa herî xirab de, 20 hûrdeman digire, heke tavilê ne diyar be ku winda li ku derê çêdibin. Eşkere ye ku hemî vê demê - 5 an 20 hûrdem - dê karûbarên me bidomînin, ku dibe ku ne baş e.
Bi rastî hûn dixwazin çi bistînin? Gelek rêyên me hene. Û pirsgirêk bi rastî çêdibin ji ber ku herikîna TCP-ya ku bêbext in berdewam dikin ku heman rêyê bikar bînin. Pêdiviya me bi tiştek heye ku rê bide me ku em di nav yek pêwendiyek TCP-ê de gelek rêçan bikar bînin. Wisa xuya dike ku çareseriyek me heye. TCP heye, ku jê re TCP-ya pir rê tê gotin, ango TCP ji bo çend rêyan. Rast e, ew ji bo karekî bi tevahî cûda hate pêşve xistin - ji bo têlefonên ku xwedan çend amûrên torê ne. Ji bo zêdekirina veguheztinê an çêkirina moda seretayî / paşvekişandinê, mekanîzmayek hate pêşve xistin ku gelek têlan (danişîn) bi zelalî ji serîlêdanê re diafirîne û dihêle hûn di bûyera têkçûnê de di navbera wan de biguhezin. An jî, wekî ku min got, xêzikê herî zêde bikin.
Lê li vir nuwazeyek heye. Ji bo ku em fêm bikin ka ew çi ye, em ê li ber çavan bigerin ka çawa têlan têne damezrandin.
Mijar bi rêz têne saz kirin. Mijara yekem pêşî tê saz kirin. Dûv re mijarên paşerojê bi karanîna cookie-ya ku jixwe di nav wê mijarê de li ser lihevkirî hatî danîn têne danîn. Û li vir pirsgirêk e.
Pirsgirêk ev e ku ger xêza yekem xwe saz neke, xêza duyemîn û sêyemîn qet dernakeve. Ango, TCP-ya pir rêça windabûna pakêtek SYN di herika yekem de çareser nake. Û heke SYN winda bibe, TCP-ya pir rêgez vediguhere TCP-ya birêkûpêk. Ev tê vê wateyê ku di hawîrdorek navendek daneyê de ew ê ji me re nebe alîkar ku pirsgirêka windahiyên di kargehê de çareser bikin û fêr bibin ku di bûyera têkçûnê de gelek rêçikan bikar bînin.
Çi dikare alîkariya me bike? Hin ji we berê ji sernavê texmîn kirine ku di çîroka meya din de qadek girîng dê qada sernavê nîşana herikîna IPv6 be. Bi rastî, ev qadek e ku di v6 de xuya dike, ew ne di v4 de ye, 20 bit dagir dike, û demek dirêj li ser karanîna wê nakokî hene. Ev pir balkêş e - nakokî hebûn, tiştek di hundurê RFC de hate rast kirin, û di heman demê de pêkanînek di kernel Linux de xuya bû, ku li ti deverek nehatiye belge kirin.
Ez we vedixwînim ku hûn bi min re li ser lêkolînek piçûk biçin. Ka em binihêrin ka di van çend salên borî de çi diqewime di kernel Linux de.
sala 2014. Endezyarek ji pargîdaniyek mezin û rêzdar girêdayîbûna nirxa etîketa herikînê bi hashê soketê re li fonksiyona kernel Linux zêde dike. Çi dixwestin li vir rast bikin? Ev bi RFC 6438 ve girêdayî ye, ku mijara jêrîn nîqaş kir. Di hundurê navenda daneyê de, IPv4 bi gelemperî di pakêtên IPv6 de tête girtin, ji ber ku kargeh bixwe IPv6 e, lê IPv4 divê bi rengek li derve were dayîn. Demek dirêj bi guhezînan re pirsgirêk hebûn ku nekarîn di bin du sernavên IP-yê de binihêrin da ku bigihîjin TCP an UDP-yê û li wir src_ports, dst_ports bibînin. Derket holê ku haş, heke hûn li her du sernavên IP-ya yekem binihêrin, hema hema rast derket. Ji bo ku ji vê yekê dûr nekevin, da ku hevsengkirina vê seyrûsefera dorpêçkirî bi rengek rast bixebite, hate pêşniyar kirin ku haşeya pakêta pêgirtî ya 5-carî li nirxa qada nîşana herikînê zêde bikin. Nêzîkî heman tişt ji bo nexşeyên din ên encapsulasyonê hate kirin, ji bo UDP, ji bo GRE, ya paşîn qada GRE Key bikar anî. Bi awayekî din, armancên li vir eşkere ne. Û bi kêmanî di wê demê de ew kêrhatî bûn.
Di sala 2015 de, pişkek nû ji heman endezyarê rêzdar tê. Ew pir balkêş e. Ew jêrîn dibêje - em ê di bûyerek rêveçûnek neyînî de haş-ê rastdar bikin. Bûyerek rêça neyînî çi ye? Ev RTO-ya ku me berê behs kir, ev e, windabûna dûvê pencereyê bûyerek bi rastî neyînî ye. Rast e, meriv texmîn dike ku ew ew e.
2016, pargîdaniyek din a navdar, di heman demê de mezin. Ew kincên paşîn ji hev vediqetîne û wusa dike ku haşaya ku me berê random çêkiribû, naha ji bo her veguheztina SYN û piştî her wextê RTO-yê diguhere. Û di vê nameyê de, ji bo cara yekem û ya paşîn, armanca dawîn tête diyar kirin - dabînkirina ku seyrûsefer di bûyera windahiyan an qerebalixiya kanalê de xwedan şiyana ku bi nermî ji nû ve were rêve kirin û pir riyan bikar bîne. Bê guman, piştî vê yekê gelek weşan hebûn, hûn dikarin bi hêsanî wan bibînin.
Her çend na, hûn nikaribin, ji ber ku li ser vê mijarê yek weşanek çênebûye. Lê em dizanin!
Û heke hûn bi tevahî fêm nakin ka çi hate kirin, ez ê niha ji we re vebêjim.
Çi hate kirin, çi fonksiyon li kernel Linux hate zêdekirin? txhash piştî her bûyerek RTO diguhezîne nirxek rasthatî. Ev encama pir neyînî ya rêvekirinê ye. Hash bi vê txhashê ve girêdayî ye, û etîketa herikînê bi hash skb ve girêdayî ye. Li vir hin hesabên li ser fonksiyonan hene; hemî hûrgulî li ser yek slaytê nayê danîn. Ger kesek meraq dike, hûn dikarin koda kernelê derbas bikin û kontrol bikin.
Li vir çi girîng e? Nirxa qada labelê ya herikînê piştî her RTO-yê diguhezîne hejmareke rasthatî. Ev bandorek çawa li ser meya TCP-ê ya bêbext dike?
Ger SACK çêbibe, tiştek nayê guhertin ji ber ku em hewl didin ku pakêtek winda ya naskirî ji nû ve bişînin. Çiqas dûr awqas baş.
Lê di mijara RTO de, bi şertê ku me etîketek herikînê li fonksiyona hash a li ser ToR zêde kiribe, dibe ku seyrûsefer rêyek cûda bigire. Û çiqas bêtir rê, şansê ku ew ê rêyek ku ji têkçûnek li ser amûrek taybetî bandor nekiriye bibîne ew qas mezintir e.
Pirsgirêkek dimîne - RTO. Bê guman, rêyek din jî heye, lê gelek dem li ser vê yekê winda dibe. 200 ms gelek e. A duyemîn bi tevahî hov e. Berê, min li ser demên ku karûbar têne mîheng kirin axivî. Ji ber vê yekê, duyemîn demjimêrek e, ku bi gelemperî ji hêla karûbar ve di asta serîlêdanê de tête mîheng kirin, û di vê yekê de karûbar jî dê bi rêkûpêk rast be. Wekî din, ez dubare dikim, RTT-ya rastîn di hundurê navendek daneya nûjen de dora 1 millisecond e.
Hûn dikarin bi demên RTO re çi bikin? Demjimêr, ku di bûyera windabûna pakêtên daneyê de berpirsiyarê RTO ye, dikare bi hêsanî ji cîhê bikarhêner were mîheng kirin: amûrek IP-yê heye, û yek ji parametreyên wê heman rto_min dihewîne. Bihesibînin ku RTO, bê guman, pêdivî ye ku ne gerdûnî were zivirandin, lê ji bo pêşgirên diyarkirî, mekanîzmayek wusa pir bikêr xuya dike.
Rast e, bi SYN_RTO re her tişt hinekî xirabtir e. Ew bi xwezayî tê xêz kirin. Kernel xwedî nirxek sabît 1 çirke ye, û ew e. Hûn nikarin ji cîhê bikarhêner bigihîjin wir. Tenê rêyek heye.
eBPF ji bo rizgariyê tê. Bi hêsanî ev bernameyên C-yê piçûk in. Ew dikarin di cîbicîkirina kernel û stûna TCP-ê de li ciyên cihê werin danîn, bi wan re hûn dikarin hejmareke pir mezin mîhengan biguherînin. Bi gelemperî, eBPF meylek demdirêj e. Li şûna ku bi dehan parametreyên nû yên sysctl qut bike û kargêriya IP-yê berfireh bike, tevger ber bi eBPF ve diçe û fonksiyona xwe berfireh dike. Bi karanîna eBPF, hûn dikarin bi dînamîk kontrolên tevliheviyê û mîhengên TCP yên cihêreng biguhezînin.
Lê ji bo me girîng e ku ew ji bo guhertina nirxên SYN_RTO were bikar anîn. Wekî din, mînakek gelemperî heye: . Li vir çi hatiye kirin? Mînak kar dike, lê bi serê xwe pir dijwar e. Li vir tê texmîn kirin ku di hundurê navenda daneyê de em 44 bitên yekem didin ber hev; heke ew li hev bikin, wê hingê em di hundurê navenda daneyê de ne. Û di vê rewşê de em nirxa wextê SYN_RTO diguherînin 4ms. Heman peywir dikare pir xweşiktir were kirin. Lê ev mînaka hêsan nîşan dide ku ev a) mimkun e; b) nisbeten sade.
Jixwe em çi dizanin? Rastiya ku mîmariya balafirê rê dide pîvandinê, dema ku em etîketa herikînê li ser ToR-ê çalak dikin û jêhatîbûna li dora deverên pirsgirêkê diherikin, ji me re zehf bikêr derdikeve. Awayê çêtirîn ku meriv nirxên RTO û SYN-RTO kêm bike ev e ku meriv bernameyên eBPF bikar bîne. Pirs dimîne: gelo karanîna etîketek herikînê ji bo hevsengiyê ewle ye? Û li vir nuwazeyek heye.
Bifikirin ku we karûbarek li ser tora we heye ku di anycast de dijî. Mixabin, wextê min tune ku ez bi hûrgulî biçim ka anycast çi ye, lê ew karûbarek belavkirî ye ku bi serverên laşî yên cihêreng ve bi heman navnîşana IP-yê ve tê gihîştin. Û li vir pirsgirêkek mimkun heye: bûyera RTO ne tenê dema ku seyrûsefer di nav qumaşê re derbas dibe çêdibe. Di heman demê de ew dikare di asta tampon ToR de jî çêbibe: gava ku bûyerek bêserûber diqewime, ew dikare li ser mêvandar jî çêbibe dema ku mêvandar tiştek dirijîne. Dema ku bûyerek RTO diqewime û ew etîketa herikînê diguhezîne. Di vê rewşê de, seyrûsefer dikare biçe mînakek din a herkesî. Ka em bihesibînin ku ev heryek dewletdar e, ew rewşek pêwendiyê vedihewîne - ew dikare L3 Balancer an karûbarek din be. Dûv re pirsgirêk derdikeve, ji ber ku piştî RTO pêwendiya TCP digihîje serverê, ku di derbarê vê pêwendiya TCP de tiştek nizane. Û heke me di navbera serverên anycast de parvekirina dewletê tune be, wê hingê seyrûsefera wusa dê were avêtin û pêwendiya TCP-ê dê têk bibe.
Hûn dikarin li vir çi bikin? Di nav hawîrdora xweya kontrolkirî de, cihê ku hûn hevsengkirina nîşana herikînê çalak dikin, hûn hewce ne ku dema ku bigihîjin serverên anycast nirxa etîketa herikê tomar bikin. Rêya herî hêsan ev e ku meriv vê yekê bi heman bernameya eBPF bike. Lê li vir xalek pir girîng heye - heke hûn tora navendek daneyê nexebitînin, lê operatorek telekomê bin, çi bikin? Pirsgirêka we jî ev e: bi hin guhertoyên Juniper û Arista dest pê dikin, ew bi xwerû di nav fonksiyonên xwe yên haş de etîketek herikînê vedihewînin - bi eşkere, ji ber sedemek ku ji min re ne diyar e. Ev dibe sedem ku hûn girêdanên TCP-ê ji bikarhênerên ku di nav tora we re derbas dibin dakêşin. Ji ber vê yekê ez pir pêşniyar dikim ku mîhengên routerên xwe li vir kontrol bikin.
Bi rengekî din, ji min re xuya dike ku em amade ne ku derbasî ceribandinan bibin.
Dema ku me nîşana herikînê li ser ToR çalak kir, ajanê eBPF, ku naha li ser mêvandaran dijî, amade kir, me biryar da ku em li benda têkçûna mezin a din nebin, lê teqînên kontrolkirî pêk bînin. Me ToR girt, ku çar girêdanên wê hene, û li ser yek ji wan dilopan saz kirin. Wan qaîdeyek xêz kir û got - naha hûn hemî pakêtan winda dikin. Wekî ku hûn li milê çepê dibînin, çavdêriya me ya per-pakêtê heye, ku daketiye 75%, ango 25% pakêtan winda dibin. Li milê rastê grafikên karûbarên ku li pişt vê ToR dijîn hene. Bi bingehîn, ev grafikên seyrûseferê yên pêwendiyên bi serverên di hundurê rakê de ne. Wekî ku hûn dikarin bibînin, ew hê kêmtir bin. Çima ew kêm bûn - ne bi 25%, lê di hin rewşan de 3-4 carî? Ger pêwendiya TCP-ê bêbext be, ew berdewam dike ku hewl bide ku bi riya girêdana şikestî bigihîje. Ev ji hêla tevgera tîpîk ya karûbarê di hundurê DC-ê de zêde dibe - ji bo yek daxwazek bikarhêner, N daxwazên karûbarên hundurîn têne çêkirin, û bersiv dê ji bikarhêner re biçe dema ku hemî çavkaniyên daneyê bersivê didin, an jî dema ku demek li serîlêdanê çêdibe. asta, ku hîn jî pêdivî ye ku were mîheng kirin. Yanî her tişt pir û pir xerab e.
Naha heman ceribandin, lê bi nirxa nîşana herikînê ve çalak e. Wekî ku hûn dikarin bibînin, li milê çepê çavdêriya meya komê bi heman 25% daket. Ev bi tevahî rast e, ji ber ku ew di derheqê veguheztinê de tiştek nizane, ew pakêtan dişîne û bi tenê rêjeya hejmara pakêtên radestkirî û windakirî dihejmêre.
Û li milê rastê bernameya karûbarê ye. Hûn ê li vir bandora hevgirtinek pirsgirêk nabînin. Di wan heman milîsaniyeyan de, seyrûsefer ji devera pirsgirêkê berbi sê girêdanên mayî yên ku ji pirsgirêkê bandor nebûbûn diherikî. Tora me heye ku xwe sax dike.
Ev slideya min a dawî ye, dema kurtkirina min e. Naha, ez hêvî dikim ku hûn zanibin ka meriv çawa torgilokek navenda daneya xwe-başkirinê ava dike. Hûn ê ne hewce ne ku hûn di nav arşîva kernel Linux-ê de derbas bibin û li wir li pêlên taybetî bigerin; hûn dizanin ku etîketa Flow di vê rewşê de pirsgirêkê çareser dike, lê hûn hewce ne ku bi baldarî nêzî vê mekanîzmayê bibin. Û ez careke din tekez dikim ku ger hûn operatorek telekomê bin, divê hûn etîketa herikînê wekî fonksiyonek hash bikar neynin, wekî din hûn ê danişînên bikarhênerên xwe xera bikin.
Pêdivî ye ku endezyarên torê veguherînek têgehî derbas bikin: tor ne bi ToR, ne bi cîhaza torê, lê bi mêvandar dest pê dike. Mînakek berbiçav ev e ku em çawa eBPF-ê hem ji bo guheztina RTO-yê hem jî ji bo sererastkirina nîşana herikînê li ser karûbarên anycast bikar tînin.
Mekanîka nîşana herikînê bê guman ji bo serîlêdanên din ên di beşa îdarî ya kontrolkirî de maqûl e. Ev dikare seyrûsefera di navbera navendên daneyê de be, an jî hûn dikarin mekanîka weha bi rengek taybetî bikar bînin da ku seyrûsefera derketinê birêve bibin. Lê ez ê li ser vê yekê ji we re bibêjim, ez hêvî dikim, carek din. Gelek spas ji bo baldariya we.
Source: www.habr.com