Šiuolaikiniuose duomenų centruose įdiegta šimtai aktyvių įrenginių, kuriems taikomas įvairių tipų stebėjimas. Tačiau net idealus inžinierius, turintis tobulą stebėjimą, sugebės teisingai reaguoti į tinklo gedimą tik per kelias minutes. Pranešime „Next Hop 2020“ konferencijoje pristačiau nuolatinės srovės tinklo projektavimo metodiką, kuri turi unikalią savybę – duomenų centras apsigydo per milisekundes. Tiksliau, inžinierius ramiai sutvarko problemą, o tarnybos tiesiog jos nepastebi.
Daugeliui tinklo inžinierių duomenų centro tinklas, žinoma, prasideda nuo ToR su jungikliu stove. ToR paprastai turi dviejų tipų nuorodas. Mažieji eina į serverius, kiti - jų yra N kartų daugiau - eina link pirmo lygio spinų, tai yra į jo uplink'us. Įkėlimo nuorodos paprastai laikomos lygiavertėmis, o srautas tarp įkėlimo nuorodų yra subalansuotas pagal maišą iš 5 kortelių, į kuriuos įeina proto, src_ip, dst_ip, src_port, dst_port. Jokių staigmenų čia nėra.
Toliau, kaip atrodo plano architektūra? Pirmojo lygio stuburai nėra sujungti vienas su kitu, o yra sujungti per superspyglius. Raidė X bus atsakinga už superstuburus; tai beveik kaip kryžminė jungtis.
Ir aišku, kad, kita vertus, tori yra prijungti prie visų pirmojo lygio stuburų. Kas svarbu šiame paveikslėlyje? Jei sąveikaujame stovo viduje, tada sąveika, žinoma, vyksta per ToR. Jei sąveika vyksta modulio viduje, tada sąveika vyksta per pirmojo lygio stuburus. Jei sąveika yra tarpmodulinė – kaip čia, ToR 1 ir ToR 2 – tada sąveika vyks ir per pirmojo, ir antrojo lygmenų stuburus.
Teoriškai tokia architektūra yra lengvai keičiama. Jei turime prievado pajėgumus, laisvos vietos duomenų centre ir iš anksto nutiestą šviesolaidį, juostų skaičių visada galima padidinti ir taip padidinti bendrą sistemos pajėgumą. Tai labai lengva padaryti ant popieriaus. Gyvenime taip būtų. Tačiau šiandienos istorija ne apie tai.
Noriu, kad būtų padarytos teisingos išvados. Duomenų centre turime daug kelių. Jie yra sąlyginai nepriklausomi. Vienas kelias duomenų centre galimas tik ToR viduje. Modulio viduje turime takų skaičių, lygų juostų skaičiui. Kelių tarp modulių skaičius yra lygus plokštumų skaičiaus ir kiekvienos plokštumos superspyglių skaičiaus sandaugai. Kad būtų aiškiau, kad suprasčiau mastelį, pateiksiu skaičius, kurie galioja vienam iš „Yandex“ duomenų centrų.
Yra aštuonios plokštumos, kiekviena turi 32 superstuburus. Dėl to paaiškėja, kad modulio viduje yra aštuoni keliai, o sąveikaujant tarp modulių jų yra jau 256.
Tai yra, jei kuriame „Cookbook“ ir bandome išmokti kurti gedimams atsparius duomenų centrus, kurie išsigydo patys, tada plokštuminė architektūra yra tinkamas pasirinkimas. Tai išsprendžia mastelio keitimo problemą ir teoriškai tai paprasta. Yra daug nepriklausomų kelių. Lieka klausimas: kaip tokia architektūra išgyvena nesėkmes? Gedimų būna įvairių. Ir mes tai aptarsime dabar.
Tegul vienas iš mūsų superstuburų „suserga“. Čia grįžau prie dviejų plokštumų architektūros. Laikysime juos kaip pavyzdį, nes paprasčiausiai bus lengviau suprasti, kas vyksta, kai yra mažiau judančių dalių. Tegul X11 susirgo. Kaip tai paveiks paslaugas, kurios gyvena duomenų centruose? Daug kas priklauso nuo to, kaip iš tikrųjų atrodo gedimas.
Jei gedimas geras, pagaunama to paties BFD automatikos lygyje, automatika su džiaugsmu uždeda problemines jungtis ir išskiria problemą, tada viskas gerai. Turime daug takų, eismas akimirksniu nukreipiamas į alternatyvius maršrutus, o tarnybos nieko nepastebės. Tai geras scenarijus.
Blogas scenarijus, jei nuolat patiriame nuostolių, o automatika nepastebi problemos. Norėdami suprasti, kaip tai veikia programą, turėsime skirti šiek tiek laiko aptarti, kaip veikia TCP.
Tikiuosi, kad nieko nešokiruosiu šia informacija: TCP yra perdavimo patvirtinimo protokolas. Tai yra, paprasčiausiu atveju siuntėjas siunčia du paketus ir gauna kaupiamąjį patvirtinimą: „Gavau du paketus“.
Po to jis išsiųs dar du paketus, ir situacija kartosis. Iš anksto atsiprašau už supaprastinimą. Šis scenarijus yra teisingas, jei langas (paketų skaičius skrydžio metu) yra du. Žinoma, bendru atveju taip nebūtinai. Tačiau lango dydis neturi įtakos paketų persiuntimo kontekstui.
Kas atsitiks, jei pamesime 3 paketą? Tokiu atveju gavėjas gaus 1, 2 ir 4 paketus. Ir jis aiškiai pasakys siuntėjui, naudodamas SACK parinktį: „Žinai, atėjo trys, bet pamestas vidurys“. Jis sako: „Ack 2, SACK 4“.
Šiuo metu siuntėjas be jokių problemų pakartoja būtent tą paketą, kuris buvo prarastas.
Bet jei paskutinis paketas lange bus prarastas, situacija atrodys visiškai kitaip.
Gavėjas gauna pirmuosius tris paketus ir pirmiausia pradeda laukti. Dėl kai kurių „Linux“ branduolio TCP paketo optimizacijų jis lauks suporuoto paketo, nebent vėliavėlės aiškiai nurodys, kad tai paskutinis paketas ar kažkas panašaus. Jis palauks, kol pasibaigs atidėtas ACK skirtasis laikas, ir tada išsiųs patvirtinimą apie pirmuosius tris paketus. Bet dabar siuntėjas lauks. Jis nežino, ar ketvirtoji pakuotė pamesta, ar netrukus atkeliaus. Ir kad tinklas nebūtų perkrautas, jis bandys palaukti, kol bus aiškus signalas, kad paketas prarastas, arba kol baigsis RTO skirtasis laikas.
Kas yra RTO skirtasis laikas? Tai yra didžiausias RTT, apskaičiuotas pagal TCP krūvą ir tam tikrą konstantą. Kokia tai konstanta, dabar aptarsime.
Bet svarbu tai, kad jei mums vėl nepasisekė ir vėl prarandamas ketvirtas paketas, tada RTO padvigubėja. Tai reiškia, kad kiekvienas nesėkmingas bandymas reiškia padvigubinti skirtąjį laiką.
Dabar pažiūrėkime, kam lygi ši bazė. Pagal numatytuosius nustatymus minimalus RTO yra 200 ms. Tai yra minimalus duomenų paketų RTO. SYN paketams jis skiriasi, 1 sekundė. Kaip matote, net pirmasis bandymas pakartotinai išsiųsti paketus užtruks 100 kartų ilgiau nei RTT duomenų centre.
Dabar grįžkime prie savo scenarijaus. Kas vyksta su paslauga? Paslauga pradeda prarasti paketus. Tegul paslaugai iš pradžių sąlyginai pasiseka ir kažką pameta lango viduryje, tada gauna SACK ir iš naujo siunčia pamestus paketus.
Bet jei nesėkmė kartojasi, turime RTO. Kas čia svarbu? Taip, mūsų tinkle yra daug kelių. Tačiau vieno konkretaus TCP ryšio TCP srautas ir toliau eis per tą patį sugedusį kamštį. Paketų praradimas, jei šis stebuklingas mūsų X11 neužgęsta savaime, nesukelia transporto srauto į neproblemingas sritis. Mes bandome pristatyti paketą per tą patį sugedusį krūvą. Tai veda prie pakopinio gedimo: duomenų centras yra sąveikaujančių programų rinkinys, o kai kurie visų šių programų TCP ryšiai pradeda blogėti, nes superspine veikia visas duomenų centre esančias programas. Kaip sakoma: jei arklio nepabadai, arklys sušlubavo; arklys sušlubavo – pranešimas nebuvo įteiktas; ataskaita nebuvo pristatyta – pralaimėjome karą. Tik čia skaičiuojama sekundėmis nuo problemos atsiradimo iki degradacijos stadijos, kurią pradeda jausti tarnybos. Tai reiškia, kad vartotojai gali kažko kažkur praleisti.
Yra du klasikiniai vienas kitą papildantys sprendimai. Pirmoji yra paslaugos, kurios bando įdėti šiaudelį ir išspręsti problemą taip: „Pataisykime ką nors TCP krūvoje. Atlikime skirtąjį laiką programos lygiu arba ilgalaikius TCP seansus su vidiniais sveikatos patikrinimais. Problema ta, kad tokie sprendimai: a) visiškai nesikeičia; b) yra labai prastai patikrintos. Tai yra, net jei paslauga netyčia sukonfigūruoja TCP steką taip, kad ji būtų geresnė, pirma, mažai tikėtina, kad ji bus taikoma visoms programoms ir visiems duomenų centrams, ir, antra, greičiausiai ji nesupras, kad tai buvo padaryta. teisingai, o kas ne. Tai yra, jis veikia, bet veikia prastai ir nesikeičia. O jei yra tinklo problema, kas kaltas? Žinoma, NOC. Ką daro NOC?
Daugelis tarnybų mano, kad NOC darbe vyksta kažkas panašaus. Bet jei atvirai, ne tik tai.
NOC klasikinėje schemoje užsiima daugelio stebėjimo sistemų kūrimu. Tai ir juodosios, ir baltosios dėžės stebėjimas. Apie juodosios dėžės stuburo stebėjimo pavyzdį Aleksandras Klimenko paskutiniame „Next Hop“. Beje, šis stebėjimas veikia. Tačiau net ir idealus stebėjimas turės laiko delsą. Paprastai tai yra kelios minutės. Jam užgesus, budintiems inžinieriams reikia laiko dar kartą patikrinti jo veikimą, lokalizuoti problemą ir užgesinti probleminę sritį. Tai yra, geriausiu atveju problemos gydymas užtrunka 5 minutes, blogiausiu – 20 minučių, jei iš karto nėra aišku, kur atsiranda nuostolių. Akivaizdu, kad visą šį laiką – 5 ar 20 minučių – mūsų paslaugos ir toliau kentės, o tai tikriausiai nėra gerai.
Ką iš tikrųjų norėtumėte gauti? Mes turime tiek daug būdų. O problemų kyla būtent todėl, kad nepasisekė TCP srautai ir toliau naudojasi tuo pačiu maršrutu. Mums reikia kažko, kas leistų mums naudoti kelis maršrutus per vieną TCP ryšį. Atrodytų, kad sprendimą turime. Yra TCP, kuris vadinamas kelių kelių TCP, tai yra, TCP keliems takams. Tiesa, jis buvo sukurtas visai kitai užduočiai – išmaniesiems telefonams, kurie turi kelis tinklo įrenginius. Siekiant maksimaliai padidinti perdavimą arba sukurti pirminį / atsarginį režimą, buvo sukurtas mechanizmas, kuris sukuria kelias gijas (seansus) skaidriai programai ir leidžia perjungti juos gedimo atveju. Arba, kaip sakiau, padidinkite seriją.
Bet čia yra niuansas. Norėdami suprasti, kas tai yra, turėsime pažvelgti į tai, kaip kuriamos gijos.
Siūlai montuojami nuosekliai. Pirmiausia įdiegiamas pirmasis siūlas. Paskesnės gijos nustatomos naudojant slapuką, dėl kurio jau buvo susitarta toje gijoje. Ir čia yra problema.
Problema ta, kad jei pirmoji gija neįsitvirtins, antroji ir trečioji gijos niekada neatsiras. Tai reiškia, kad kelių kelių TCP neišsprendžia SYN paketo praradimo pirmajame sraute. Ir jei SYN prarandamas, kelių kelių TCP virsta įprastu TCP. Tai reiškia, kad duomenų centro aplinkoje tai nepadės mums išspręsti nuostolių gamykloje problemos ir išmokti naudotis keliais keliais gedimo atveju.
Kas gali mums padėti? Kai kurie iš jūsų jau spėjo iš pavadinimo, kad svarbus laukas mūsų tolimesnėje istorijoje bus IPv6 srauto etiketės antraštės laukas. Iš tiesų, tai yra laukas, kuris rodomas 6 versijoje, jo nėra v4, jis užima 20 bitų ir ilgą laiką kilo ginčų dėl jo naudojimo. Tai labai įdomu - kilo ginčų, kažkas buvo pataisyta RFC viduje, o tuo pačiu metu Linux branduolyje atsirado diegimas, kuris niekur nebuvo dokumentuotas.
Kviečiu jus kartu su manimi atlikti nedidelį tyrimą. Pažiūrėkime, kas per pastaruosius kelerius metus vyko „Linux“ branduolyje.
2014 metai. Vienos didelės ir gerbiamos įmonės inžinierius prie Linux branduolio funkcionalumo prideda srauto etiketės reikšmės priklausomybę nuo lizdo maišos. Ką jie čia bandė ištaisyti? Tai susiję su RFC 6438, kuriame buvo aptarta ši problema. Duomenų centro viduje IPv4 dažnai būna įdėtas į IPv6 paketus, nes pati gamykla yra IPv6, bet IPv4 kažkaip reikia duoti išorėje. Ilgą laiką buvo problemų su jungikliais, kurie negalėjo ieškoti po dvi IP antraštes, kad galėtų patekti į TCP arba UDP ir rasti ten src_ports, dst_ports. Paaiškėjo, kad maiša, jei pažvelgsite į pirmąsias dvi IP antraštes, pasirodė beveik ištaisyta. Siekiant to išvengti, kad šio įkapsuliuoto srauto balansavimas veiktų tinkamai, buvo pasiūlyta į srauto etiketės lauko reikšmę įtraukti 5 kartotinio paketo maišą. Maždaug tas pats buvo padaryta ir kitoms inkapsuliavimo schemoms, UDP, GRE, pastaroji naudojo GRE rakto lauką. Vienaip ar kitaip, tikslai čia aiškūs. Ir bent tuo metu jie buvo naudingi.
2015 m. iš to paties gerbiamo inžinieriaus atkeliavo naujas pleistras. Jis labai įdomus. Jame rašoma taip – atsitiktinai suskirstysime maišą neigiamo maršruto parinkimo įvykio atveju. Kas yra neigiamas maršruto parinkimo įvykis? Tai yra RTO, apie kurį kalbėjome anksčiau, tai yra, lango uodegos praradimas yra tikrai neigiamas įvykis. Tiesa, gana sunku atspėti, kad būtent tai.
2016 m., kita patikima įmonė, taip pat didelė. Jis išardo paskutinius ramentus ir padaro taip, kad maiša, kurią anksčiau padarėme atsitiktinai, dabar pasikeičia kiekvieną SYN pakartotinį siuntimą ir po kiekvieno RTO skirtojo laiko. O šiame laiške pirmą ir paskutinį kartą nurodomas galutinis tikslas – užtikrinti, kad srautas nuostolių ar kanalų perkrovos atveju turėtų galimybę švelniai nukreipti kitą maršrutą ir naudoti kelis kelius. Žinoma, po to buvo daug publikacijų, nesunkiai juos rasite.
Nors ne, negalite, nes nebuvo nei vienos publikacijos šia tema. Bet mes žinome!
Ir jei jūs visiškai nesuprantate, kas buvo padaryta, aš jums pasakysiu dabar.
Kas buvo padaryta, kokios funkcijos buvo įtrauktos į Linux branduolį? txhash pasikeičia į atsitiktinę reikšmę po kiekvieno RTO įvykio. Tai labai neigiamas maršruto parinkimo rezultatas. Maiša priklauso nuo šios txhash, o srauto etiketė priklauso nuo skb maišos. Čia yra keletas funkcijų skaičiavimų; visos detalės negali būti pateikiamos vienoje skaidrėje. Jei kam įdomu, galite peržiūrėti branduolio kodą ir patikrinti.
Kas čia svarbu? Srauto etiketės lauko reikšmė po kiekvieno RTO pasikeičia į atsitiktinį skaičių. Kaip tai paveikia mūsų nelaimingą TCP srautą?
Jei įvyksta SACK, niekas nepasikeičia, nes bandome iš naujo išsiųsti žinomą prarastą paketą. Kol kas viskas gerai.
Tačiau RTO atveju, jei prie ToR maišos funkcijos pridėjome srauto etiketę, eismas gali vykti kitu maršrutu. Ir kuo daugiau juostų, tuo didesnė tikimybė, kad jis suras kelią, kurio nepaveiktų konkretaus įrenginio gedimas.
Viena problema išlieka – RTO. Žinoma, yra ir kitas maršrutas, bet tam sugaištama daug laiko. 200 ms yra daug. Antrasis yra visiškai laukinis. Anksčiau kalbėjau apie skirtąjį laiką, kai paslaugos yra sukonfigūruotos. Taigi, sekundė yra skirtasis laikas, kurį paprastai sukonfigūruoja paslauga programos lygiu, ir šiuo atveju paslauga bus netgi gana teisinga. Be to, kartoju, tikrasis RTT šiuolaikiniame duomenų centre yra maždaug 1 milisekundė.
Ką galite padaryti su RTO skirtuoju laiku? Timeout, kuris yra atsakingas už RTO praradus duomenų paketus, gali būti gana lengvai sukonfigūruojamas iš vartotojo erdvės: yra IP programa, o viename iš jos parametrų yra tas pats rto_min. Atsižvelgiant į tai, kad RTO, žinoma, reikia pasukti ne globaliai, o tam tikriems priešdams, toks mechanizmas atrodo gana veikiantis.
Tiesa, su SYN_RTO viskas yra kiek blogiau. Jis yra natūraliai prikaltas. Branduolys turi fiksuotą 1 sekundės reikšmę, ir viskas. Negalite ten pasiekti iš naudotojo vietos. Yra tik vienas būdas.
eBPF ateina į pagalbą. Paprasčiau tariant, tai yra mažos C programos. Jas galima įterpti į kabliukus įvairiose branduolio ir TCP stack vykdymo vietose, su kuriais galima pakeisti labai daug nustatymų. Apskritai eBPF yra ilgalaikė tendencija. Užuot sumažinę daugybę naujų sysctl parametrų ir išplėtę IP naudingumą, judėjimas juda link eBPF ir plečia jo funkcionalumą. Naudodami eBPF galite dinamiškai keisti perkrovos valdiklius ir įvairius kitus TCP nustatymus.
Tačiau mums svarbu, kad jį būtų galima naudoti norint pakeisti SYN_RTO reikšmes. Be to, yra viešai paskelbtas pavyzdys: . Kas čia padaryta? Pavyzdys veikia, bet pats savaime yra labai grubus. Čia daroma prielaida, kad duomenų centre lyginame pirmuosius 44 bitus; jei jie sutampa, mes esame duomenų centro viduje. Ir šiuo atveju pakeičiame SYN_RTO skirtojo laiko reikšmę į 4ms. Tą pačią užduotį galima atlikti daug elegantiškiau. Tačiau šis paprastas pavyzdys rodo, kad tai a) įmanoma; b) gana paprasta.
Ką mes jau žinome? Tai, kad plokštumos architektūra leidžia keisti mastelį, mums labai naudinga, kai įjungiame srauto etiketę ToR ir gauname galimybę tekėti aplink problemines sritis. Geriausias būdas sumažinti RTO ir SYN-RTO reikšmes yra naudoti eBPF programas. Lieka klausimas: ar saugu naudoti srauto etiketę balansavimui? Ir čia yra niuansas.
Tarkime, kad jūsų tinkle yra paslauga, kuri veikia anycast. Deja, neturiu laiko detalizuoti, kas yra anycast, bet tai paskirstyta paslauga su skirtingais fiziniais serveriais, pasiekiamais per tą patį IP adresą. Ir čia yra galima problema: RTO įvykis gali įvykti ne tik tada, kai eismas eina per audinį. Tai taip pat gali įvykti ToR buferio lygyje: kai įvyksta incast įvykis, jis gali įvykti net pagrindiniame kompiuteryje, kai pagrindinis kompiuteris ką nors išlieja. Kai įvyksta RTO įvykis ir jis pakeičia srauto etiketę. Tokiu atveju srautas gali būti nukreiptas į kitą bet kokio perdavimo egzempliorių. Tarkime, kad tai yra būseną palaikanti bet kokia transliacija, joje yra ryšio būsena – tai gali būti L3 Balancer arba kita paslauga. Tada iškyla problema, nes po RTO TCP ryšys ateina į serverį, kuris nieko nežino apie šį TCP ryšį. Ir jei mes neturime būsenos dalijimosi tarp anycast serverių, tada toks srautas bus nutrauktas ir TCP ryšys nutrūks.
Ką čia galima padaryti? Valdomoje aplinkoje, kurioje įgalinate srauto etiketės balansavimą, turite įrašyti srauto etiketės reikšmę, kai pasiekiate anycast serverius. Lengviausias būdas tai padaryti naudojant tą pačią eBPF programą. Tačiau čia yra labai svarbus momentas – ką daryti, jei nevaldote duomenų centro tinklo, bet esate telekomunikacijų operatorius? Tai ir jūsų problema: pradedant tam tikromis Juniper ir Arista versijomis, jos pagal numatytuosius nustatymus į maišos funkcijas įtraukia srauto etiketę – atvirai kalbant, dėl man neaiškios priežasties. Dėl to jūsų tinkle gali nutrūkti vartotojų TCP ryšiai. Todėl labai rekomenduoju čia patikrinti maršrutizatoriaus nustatymus.
Vienaip ar kitaip, man atrodo, kad esame pasiruošę pereiti prie eksperimentų.
Kai įgalinome srauto etiketę ToR, paruošėme eBPF agentą, kuris dabar gyvena pagrindiniuose kompiuteriuose, nusprendėme nelaukti kito didelio gedimo, o surengti valdomus sprogimus. Mes paėmėme ToR, kuris turi keturias aukštyn siunčiamas nuorodas, ir viename iš jų nustatėme lašus. Jie nubraižė taisyklę ir pasakė – dabar jūs prarasite visus paketus. Kaip matote kairėje, mes turime vieno paketo stebėjimą, kuris sumažėjo iki 75%, tai yra, 25% paketų prarandami. Dešinėje yra paslaugų, veikiančių už šio ToR, grafikai. Iš esmės tai yra sąsajų su serveriais, esančių stovo viduje, srauto grafikai. Kaip matote, jie nugrimzdo dar žemiau. Kodėl jie nukrito žemiau – ne 25%, o kai kuriais atvejais 3-4 kartus? Jei TCP ryšys nesiseka, jis ir toliau bando pasiekti per nutrūkusią sankryžą. Tai apsunkina tipiškas paslaugos elgesys DC viduje – vienai vartotojo užklausai sugeneruojama N užklausų į vidines paslaugas, o atsakymas bus išsiųstas vartotojui, kai atsakys visi duomenų šaltiniai, arba kai programai pasibaigs skirtasis laikas. lygį, kurį dar reikia sukonfigūruoti. Tai yra, viskas yra labai labai blogai.
Dabar tas pats eksperimentas, bet su įjungta srauto etiketės reikšme. Kaip matote, kairėje pusėje mūsų partijos stebėjimas sumažėjo tais pačiais 25%. Tai visiškai teisinga, nes ji nieko nežino apie pakartotinius siuntimus, siunčia paketus ir tiesiog skaičiuoja pristatytų ir prarastų paketų santykį.
O dešinėje – aptarnavimo grafikas. Probleminio sąnario efekto čia nerasite. Per tas pačias milisekundes srautas tekėjo iš probleminės srities į tris likusias įkėlimo nuorodas, kurių problema nepaveikė. Turime tinklą, kuris gydo pats.
Tai paskutinė mano skaidrė, laikas apibendrinti. Dabar tikiuosi, kad žinote, kaip sukurti savaiminio gydymo duomenų centrų tinklą. Jums nereikės naršyti Linux branduolio archyvo ir ten ieškoti specialių pataisų; žinote, kad etiketė „Flow“ šiuo atveju išsprendžia problemą, tačiau reikia atidžiai kreiptis į šį mechanizmą. Ir dar kartą pabrėžiu, kad jei esate telekomunikacijų operatorius, neturėtumėte naudoti srauto etiketės kaip maišos funkcijos, kitaip sutrikdysite savo vartotojų seansus.
Tinklo inžinieriai turi atlikti konceptualų pokytį: tinklas prasideda ne nuo ToR, ne nuo tinklo įrenginio, o nuo pagrindinio kompiuterio. Gana ryškus pavyzdys yra tai, kaip mes naudojame eBPF, norėdami pakeisti RTO ir pritvirtinti srauto etiketę prie anycast paslaugų.
Srauto etikečių mechanika tikrai tinka kitoms valdomo administracinio segmento reikmėms. Tai gali būti srautas tarp duomenų centrų arba galite naudoti tokią mechaniką ypatingu būdu išeinančiam srautui valdyti. Bet apie tai, tikiuosi, papasakosiu kitą kartą. Labai ačiū už Jūsų dėmesį.
Šaltinis: www.habr.com