D'Netzwierk, dat sech selwer heelt: D'Magie vum Flow-Label an den Core Detective LinuxYandex-Rapport

Modern Datenzenteren hunn Honnerte vun aktive Geräter installéiert, déi duerch verschidden Aarte vu Iwwerwaachung ofgedeckt sinn. Awer och en idealen Ingenieur mat enger perfekter Iwwerwaachung an der Hand wäert fäeg sinn an nëmmen e puer Minutten op en Netzfehler korrekt ze reagéieren. An engem Bericht op der Next Hop 2020 Konferenz hunn ech eng DC Network Design Methodik presentéiert, déi eng eenzegaarteg Feature huet - den Datacenter heelt sech a Millisekonnen. Méi präzis fixéiert den Ingenieur de Problem roueg, während d'Servicer et einfach net bemierken.

- Fir unzefänken, ginn ech eng zimlech detailléiert Aféierung fir déi, déi d'Struktur vun engem modernen DC net bewosst sinn.


Fir vill Reseau Ingenieuren fänkt engem Daten Zentrum Reseau, natierlech, mat ToR, mat engem Schalter am Rack. ToR huet normalerweis zwou Zorte vu Linken. Déi Kleng ginn op d'Serveren, anerer - et gi N Mol méi vun hinnen - ginn op d'Spines vum éischte Niveau, dat heescht op seng Uplinks. Uplinks ginn normalerweis als gläich ugesinn, an de Verkéier tëscht Uplinks ass equilibréiert baséiert op engem Hash vu 5-tuple, deen Proto, src_ip, dst_ip, src_port, dst_port enthält. Keng Iwwerraschungen hei.


Als nächst, wéi gesäit d'Planarchitektur aus? Spines vum éischte Niveau sinn net matenee verbonnen, awer sinn duerch Superspines verbonnen. De Bréif X wäert verantwortlech sinn fir Superspines; et ass bal wéi e Kräizverbindung.


An et ass kloer datt, op der anerer Säit, Tori mat all Wirbelsäule vum éischte Niveau verbonne sinn. Wat ass wichteg an dësem Bild? Wa mir Interaktioun am Rack hunn, da geet d'Interaktioun natierlech duerch ToR. Wann d'Interaktioun am Modul geschitt ass, da geschitt d'Interaktioun duerch den éischte Niveau Spines. Wann d'Interaktioun intermodular ass - wéi hei, ToR 1 an ToR 2 - da wäert d'Interaktioun duerch Spinne vum éischten an zweeten Niveau goen.


An der Theorie ass sou eng Architektur einfach skalierbar. Wa mir Port Kapazitéit hunn, Ersatzraum am Rechenzentrum a pre-laid Faser, da kann d'Zuel vun de Bunnen ëmmer erhéicht ginn, an doduerch d'Gesamtkapazitéit vum System erhéijen. Dëst ass ganz einfach op Pabeier ze maachen. Et wier esou am Liewen. Mä d'Geschicht vun haut ass net doriwwer.


Ech wëll datt déi richteg Conclusiounen gezunn ginn. Mir hu vill Weeër am Rechenzentrum. Si sinn bedingt onofhängeg. Ee Wee am Rechenzentrum ass nëmme méiglech bannent ToR. Bannen am Modul hu mir d'Zuel vun de Weeër gläich wéi d'Zuel vun de Bunnen. D'Zuel vun de Weeër tëscht Moduler entsprécht dem Produkt vun der Unzuel vun de Fligeren an der Unzuel vun de Superspinen an all Fliger. Fir et méi kloer ze maachen, fir e Sënn vun der Skala ze kréien, ginn ech Zuelen déi valabel sinn fir ee vun de Yandex Datenzenteren.


Et ginn aacht Fligeren, all Fliger huet 32 ​​Superspines. Als Resultat stellt sech eraus datt et aacht Weeër am Modul sinn, a mat Intermodule Interaktioun sinn et schonn 256 vun hinnen.

Dat ass, wa mir Cookbook entwéckelen, probéieren ze léieren wéi Feeler-tolerant Datenzentere bauen déi sech selwer heelen, dann ass d'planar Architektur déi richteg Wiel. Et léist de Skaléierungsproblem, an an der Theorie ass et einfach. Et gi vill onofhängeg Weeër. D'Fro bleift: Wéi iwwerlieft esou eng Architektur Feeler? Et gi verschidde Feeler. A mir wäerten dat elo diskutéieren.


Loosst ee vun eise Superspines "krank ginn". Hei sinn ech zréck an d'Zweeplaner Architektur. Mir wäerte mat dësen als e Beispill halen well et einfach méi einfach ass ze gesinn wat mat manner bewegt Deeler lass ass. Loosst X11 krank ginn. Wéi wäert dëst d'Servicer beaflossen déi an den Datenzenter liewen? Vill hänkt dovun of wéi den Echec eigentlech ausgesäit.


Wann de Versoen gutt ass, gëtt et um Automatiséierungsniveau vum selwechte BFD gefaangen, d'Automatisatioun setzt glécklech déi problematesch Gelenker an isoléiert de Problem, dann ass alles gutt. Mir hu vill Weeër, de Verkéier gëtt direkt op alternativ Strecken ëmgeleet, a Servicer wäerten näischt bemierken. Dëst ass e gutt Skript.


E schlechte Szenario ass wa mir konstante Verloschter hunn, an d'Automatisatioun bemierkt de Problem net. Fir ze verstoen wéi dëst eng Applikatioun beaflosst, musse mir e bëssen Zäit verbréngen fir ze diskutéieren wéi TCP funktionnéiert.


Ech hoffen ech schockéieren keen mat dëser Informatioun: TCP ass eng Transmissioun Confirmatiouns Protokoll. Dat ass, am einfachsten Fall, schéckt de Sender zwee Päck a kritt e kumulativen Accord op hinnen: "Ech hunn zwee Päck kritt."


Duerno wäert hien zwee méi Päck schécken, an d'Situatioun wäert widderhuelen. Ech entschëllegt am Viraus fir e puer Vereinfachung. Dëst Szenario ass richteg wann d'Fënster (d'Zuel vun de Paketen am Fluch) zwee ass. Natierlech ass dat am allgemenge Fall net onbedéngt de Fall. Awer d'Fënstergréisst beaflosst net de Paket Forward Kontext.


Wat geschitt wa mir Paket 3 verléieren? An dësem Fall kritt den Empfänger Pakete 1, 2 a 4. An hie wäert dem Sender explizit soen mat der SACK Optioun: "Dir wësst, dräi sinn ukomm, awer d'Mëtt war verluer." Hie seet: "Ack 2, SACK 4."


Zu dësem Moment widderhëlt de Sender ouni Probleemer genau dee Paket dee verluer ass.


Awer wann de leschte Paket an der Fënster verluer ass, gesäit d'Situatioun ganz anescht aus.

Den Empfänger kritt déi éischt dräi Paketen a fänkt un ze waarden. Dank e puer Optimiséierungen am Kernel TCP Stack, Linux Et waart op e passenden Pakett, ausser et gëtt e explizite Fändel, deen ugeet, datt et de leschte Pakett ass oder eppes ähnleches. Et waart bis den Delayed ACK Timeout ofgelaf ass an dann eng Bestätegung fir déi éischt dräi Pakett schéckt. Mee elo muss den Absender waarden. Et weess net, ob de véierte Pakett verluer gaangen ass oder kuerz drop ukënnt. Fir d'Netzwierk net ze iwwerbelaascht, probéiert et ze waarden, bis et eng explizit Indikatioun gëtt, datt de Pakett verluer gaangen ass oder bis den RTO Timeout ofgelaf ass.


Wat ass RTO Timeout? Dëst ass de Maximum vum RTT berechent vum TCP Stack an e puer konstante. Wat fir eng Konstant dëst ass, wäerte mir elo diskutéieren.


Awer déi wichteg Saach ass datt wa mir erëm Pech hunn an de véierte Paket erëm verluer ass, da verduebelt den RTO. Dat ass, all Mëssgléckt Versuch heescht Verdueblung der Timeout.


Loosst eis elo kucken wat dës Basis gläich ass. Par défaut ass de Minimum RTO 200 ms. Dëst ass de Minimum RTO fir Datepakete. Fir SYN Pakete ass et anescht, 1 Sekonn. Wéi Dir gesitt, wäert och den éischte Versuch, Pakete nei ze schécken, 100 Mol méi laang daueren wéi de RTT am Rechenzentrum.


Komme mer elo zréck op eise Szenario. Wat ass lass mam Service? De Service fänkt Päck ze verléieren. Loosst de Service fir d'éischt bedingt Gléck sinn a verléiert eppes an der Mëtt vun der Fënster, da kritt en e SACK a schéckt d'Päckchen erëm, déi verluer waren.


Awer wann de Pech sech widderhëlt, dann hu mir en RTO. Wat ass hei wichteg? Jo, mir hu vill Weeër an eisem Netz. Awer den TCP Traffic vun enger bestëmmter TCP Verbindung wäert weider duerch dee selwechte gebrochene Stack goen. Paketverloschter, virausgesat datt dës magesch X11 vun eis net eleng erausgeet, féiert net zum Verkéier, deen a Beräicher fléisst, déi net problematesch sinn. Mir probéieren de Paket duerch dee selwechte gebrochene Stack ze liwweren. Dëst féiert zu engem Kaskadesfehler: en Datenzenter ass eng Rei vun interagéierend Uwendungen, an e puer vun den TCP Verbindunge vun all dësen Uwendungen fänken un ze degradéieren - well Superspine all Uwendungen beaflosst déi am Rechenzentrum existéieren. Wéi de Spréchwuert seet: Wann Dir kee Päerd schung, ass d'Päerd hänke gelooss; d'Päerd goung labber - de Rapport war net geliwwert; de Bericht gouf net geliwwert - mir hunn de Krich verluer. Nëmmen hei ass de Grof a Sekonnen aus dem Moment wou de Problem entsteet bis zur Etapp vun der Degradatioun, déi d'Servicer ufänken ze fillen. Dëst bedeit datt d'Benotzer iergendwou eppes verpassen.


Et ginn zwou klassesch Léisungen déi sech ergänzen. Déi éischt ass Servicer déi probéieren Stréi ze setzen an de Problem esou ze léisen: "Loosst eis eppes am TCP Stack upassen. Loosst eis Timeouts um Applikatiounsniveau maachen oder laang lieweg TCP Sessiounen mat internen Gesondheetschecken. De Problem ass datt esou Léisungen: a) guer net skaléieren; b) si ganz schlecht gepréift. Dat ass, och wann de Service zoufälleg den TCP Stack konfiguréiert op eng Manéier déi et besser mécht, éischtens ass et onwahrscheinlech fir all Uwendungen an all Datenzenter applicabel ze sinn, an zweetens, héchstwahrscheinlech, wäert et net verstoen datt et gemaach gouf. richteg, a wat net. Dat ass, et funktionnéiert, awer et funktionnéiert schlecht a skaléiert net. A wann et en Netzproblem ass, wien ass Schold? Natierlech, NOC. Wat mécht NOC?

Vill Servicer gleewen datt an der NOC Aarbecht esou eppes geschitt. Awer fir éierlech ze sinn, net nëmmen dat.


NOC am klassesche Schema beschäftegt sech mat der Entwécklung vu ville Iwwerwaachungssystemer. Dëst si béid Black Box a White Box Iwwerwaachung. Iwwer e Beispill vu Black Box Wirbelsäule Iwwerwaachung erzielt Alexander Klimenko um leschte Next Hop. Iwwregens funktionnéiert dës Iwwerwaachung. Awer och ideal Iwwerwaachung wäert eng Zäitlag hunn. Normalerweis ass dëst e puer Minutten. Nodeems et ofgeet, brauche d'Ingenieuren op der Pflicht Zäit fir seng Operatioun z'iwwerpréiwen, de Problem lokaliséieren an dann de Problemberäich auszeschléissen. Dat heescht, am beschte Fall dauert d'Behandlung vum Problem 5 Minutten, am schlëmmste Fall 20 Minutten, wann et net direkt kloer ass, wou d'Verloschter optrieden. Et ass kloer datt all dës Zäit - 5 oder 20 Minutten - eis Servicer weider leiden, wat wahrscheinlech net gutt ass.


Wat géift Dir wierklech gär kréien? Mir hunn esou vill Weeër. A Problemer entstinn genee well TCP-Flows déi onglécklech sinn, weider déiselwecht Streck benotzen. Mir brauchen eppes wat eis erlaabt verschidde Strecken an enger eenzeger TCP Verbindung ze benotzen. Et géif schéngen datt mir eng Léisung hunn. Et gëtt TCP, wat Multipath TCP genannt gëtt, dat heescht TCP fir verschidde Weeër. True, et gouf fir eng ganz aner Aufgab entwéckelt - fir Smartphones déi verschidde Netzwierkapparater hunn. Fir den Transfert ze maximéieren oder de Primär-/Backup-Modus ze maachen, gouf e Mechanismus entwéckelt, dee verschidde Threads (Sessiounen) transparent fir d'Applikatioun erstellt an Iech erlaabt Iech tëscht hinnen am Fall vun engem Feeler ze wiesselen. Oder, wéi gesot, d'Streck maximéieren.

Awer et gëtt eng Nuance hei. Fir ze verstoen wat et ass, musse mir kucken wéi Threads etabléiert sinn.


Threads ginn sequenziell installéiert. Den éischte Fuedem gëtt als éischt installéiert. Déi nächst Threads ginn dann mat dem Cookie gesat, dee schonn an deem Thread ausgemaach gouf. An hei ass de Problem.


De Problem ass datt wann den éischte Fuedem sech net feststellt, da wäerten déi zweet an drëtt Fuedem ni entstoen. Dat ass, Multipath TCP léist net de Verloscht vun engem SYN Paket am éischte Flux. A wann de SYN verluer ass, gëtt Multipath TCP a regelméisseg TCP. Dëst bedeit datt an engem Datenzenter Ëmfeld et eis net hëlleft de Problem vu Verloschter an der Fabrik ze léisen a léiere verschidde Weeër am Fall vun engem Echec ze benotzen.


Wat kann eis hëllefen? E puer vun iech hunn aus dem Titel scho geroden, datt e wichtegt Feld an eiser weiderer Diskussioun den IPv6 Flow Label Header Feld wäert sinn. Tatsächlech besetzt dëst Feld, dat a v6 erschéngt an a v4 feelt, 20 Bits, a seng Notzung war Objet vu vill Debatt. Dëst ass ganz interessant - et gouf Debatt, e puer Saache goufen an RFCs gefléckt, an an Linux- gläichzäiteg ass eng Implementatioun am Kernel opgetrueden, déi ni nirgendwou dokumentéiert gouf.


Ech invitéieren Iech, mat mir bei enger klenger Enquête matzemaachen. Loosst eis kucken, wat am Kär lass war. Linux an de leschte Joren.

2014. En Ingenieur vun enger grousser a renomméierter Firma füügt Funktionalitéiten zum Kernel bäi Linux D'Ofhängegkeet vum Flow-Label-Wäert vum Socket-Hash. Wat wollten se hei léisen? Dëst hänkt mam RFC 6438 zesummen, deen de folgende Problem diskutéiert huet. An engem Datenzentrum ass IPv4 dacks an IPv6-Päcketen agekapselt, well de Fabric selwer IPv6 ass, awer IPv4 muss extern geliwwert ginn. Laang Zäit gouf et Problemer mat Switchen, déi net ënner zwee IP-Header kucke konnten, fir op TCP oder UDP ze kommen a src_ports an dst_ports ze fannen. Dëst huet bedeit, datt den Hash, wann een déi éischt zwee IP-Header gekuckt huet, praktesch fixéiert war. Fir dëst ze vermeiden an e richtegt Ausbalancéiere vun dësem agekapselten Traffic ze garantéieren, gouf virgeschloen, den Hash vum 5-Tuple-agekapselten Pakett an de Flow-Label-Feld bäizefügen. Ongeféier datselwecht gouf fir aner Kapselungsschemae gemaach, fir UDP a fir GRE, déi lescht benotzt de GRE Key-Feld. Op alle Fall sinn d'Ziler hei kloer. An op d'mannst zu deem Zäitpunkt waren se nëtzlech.

Am Joer 2015 kënnt en neie Patch vum selwechte respektéierten Ingenieur. Hien ass ganz interessant. Et seet déi folgend - mir wäerten den Hash zoufälleg am Fall vun engem negativen Routing Event. Wat ass en negativen Routing Event? Dëst ass den RTO, dee mir virdru diskutéiert hunn, dat heescht, de Verloscht vum Schwanz vun der Fënster ass en Event dat wierklech negativ ass. True, et ass relativ schwéier ze roden datt dëst et ass.

2016, aner unerkannten Firma, och grouss. Et disassembléiert déi lescht Krutchen a mécht et sou datt den Hash, dee mir virdru zoufälleg gemaach hunn, elo ännert fir all SYN Retransmission an no all RTO Timeout. An an dësem Bréif gëtt fir d'éischt a lescht Kéier den ultimativen Zil uginn - fir sécherzestellen datt de Verkéier am Fall vu Verloschter oder Kanalstau d'Méiglechkeet huet, sanft ëmgeleet ze ginn a verschidde Weeër ze benotzen. Natierlech, duerno goufen et vill Publikatiounen, Dir kënnt se einfach fannen.

Obwuel nee, Dir kënnt net, well et net eng eenzeg Publikatioun zu dësem Thema gouf. Mee mir wëssen!

A wann Dir net ganz versteet wat gemaach gouf, wäert ech Iech elo soen.


Wat gouf gemaach, wéi eng Funktionalitéit gouf dem Kernel bäigefüügt? Linux? Den txhash ännert sech no all RTO-Event op e zoufällege Wäert. Dëst ass datselwecht negativt Routing-Resultat. Den Hash hänkt vun dësem txhash of, an de Flow-Label hänkt vum skb-Hash of. Et gëtt e puer funktionell Erklärungen, awer eng Folie wäert net all Detailer ofdecken. Wann iergendeen interesséiert ass, kënnt Dir de Kernelcode duerchschrëtten a kontrolléieren.

Wat ass hei wichteg? De Wäert vun der Flux Label Terrain Ännerungen op eng zoufälleg Zuel no all RTO. Wéi beaflosst dëst eisen onglécklechen TCP Stream?


Wann e SACK geschitt, ännert näischt well mir probéieren e bekannte verluerene Paket nei ze schécken. Sou wäit sou gutt.


Awer am Fall vun RTO, virausgesat datt mir e Flow Label un d'Hash Funktioun op ToR bäigefüügt hunn, kann de Verkéier eng aner Streck huelen. A wat méi Bunnen, wat méi grouss ass d'Chance datt et e Wee fënnt, deen net vun engem Ausfall op engem spezifeschen Apparat betraff ass.


Ee Problem bleift - RTO. Natierlech gëtt et eng aner Streck, awer vill Zäit gëtt op dësem verschwend. 200 ms ass vill. Eng zweet ass absolut wëll. Virdrun hunn ech iwwer Timeouts geschwat datt Servicer konfiguréiert sinn. Also, eng zweet ass en Timeout, deen normalerweis vum Service um Applikatiounsniveau konfiguréiert ass, an an dësem wäert de Service souguer relativ richteg sinn. Ausserdeem, ech widderhuelen, de richtege RTT an engem modernen Datenzenter ass ongeféier 1 Millisekonnen.


Wat kënnt Dir mat RTO Timeouts maachen? Den Timeout, dee verantwortlech ass fir RTO am Fall vu Verloscht vun Datepäck, kann relativ einfach aus dem Benotzerraum konfiguréiert ginn: et gëtt en IP-Utility, an ee vu senge Parameteren enthält dee selwechte rto_min. Bedenkt datt RTO, natierlech, muss net global ugepasst ginn, mä fir gegebene Präfixe, gesäit esou e Mechanismus ganz funktionell.


Richteg, mat SYN_RTO ass alles e bësse méi schlëmm. Et ass natiirlech vernoléissegt. De Kernel huet e fixe Wäert vun 1 Sekonn, an dat ass et. Dir kënnt net do aus Benotzer Raum erreechen. Et gëtt nëmmen ee Wee.


eBPF kënnt zur Rettung. Fir et einfach ze soen, dat sinn kleng Programmer C. Si kënnen op verschiddene Plazen an der Ausféierung vum Kernel-Stack an dem TCP-Stack an Haken agesat ginn, mat deenen Dir eng ganz grouss Unzuel vun Astellunge ännere kënnt. Am Allgemengen ass eBPF e laangfristeg Trend. Amplaz Dosende vun neie sysctl Parameteren ze schneiden an d'IP Utility auszebauen, geet d'Bewegung Richtung eBPF an erweidert seng Funktionalitéit. Mat eBPF kënnt Dir dynamesch Stau Kontrollen a verschidde aner TCP Astellungen änneren.


Awer et ass wichteg fir eis datt et benotzt ka ginn fir d'SYN_RTO Wäerter z'änneren. Ausserdeem gëtt et en ëffentlech gepost Beispill: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. Wat ass hei gemaach ginn? D'Beispill funktionnéiert, awer u sech ass ganz rau. Hei gëtt ugeholl datt mir am Datenzenter déi éischt 44 Bits vergläichen; wa se passen, da si mir am Rechenzentrum. An an dësem Fall änneren mir den SYN_RTO Timeout Wäert op 4ms. Déi selwecht Aufgab kann vill méi elegant gemaach ginn. Awer dëst einfacht Beispill weist datt dëst a) méiglech ass; b) relativ einfach.

Wat wësse mer schonn? D'Tatsaach datt d'Fligerarchitektur d'Skaléierung erlaabt, et stellt sech eraus fir eis extrem nëtzlech wann mir de Flow Label op ToR aktivéieren an d'Fäegkeet kréien ronderëm Problemberäicher ze fléien. De beschte Wee fir RTO a SYN-RTO Wäerter ze reduzéieren ass eBPF Programmer ze benotzen. D'Fro bleift: Ass et sécher e Flow Label fir d'Balance ze benotzen? An et gëtt eng Nuance hei.


Ugeholl Dir hutt e Service op Ärem Netz deen an Anycast lieft. Leider hunn ech keng Zäit fir am Detail ze goen iwwer wat Anycast ass, awer et ass e verdeelt Service mat verschiddene kierperleche Serveren zougänglech iwwer déiselwecht IP Adress. An hei ass e méigleche Problem: den RTO Event kann net nëmme geschéien wann de Verkéier duerch de Stoff passéiert. Et kann och um ToR Puffer Niveau optrieden: wann en Incast Event geschitt, kann et souguer um Host geschéien wann de Host eppes spillt. Wann en RTO Event geschitt an et ännert de Flow Label. An dësem Fall kann de Verkéier op eng aner Anycast Instanz goen. Loosst eis unhuelen datt dëst e stateful Anycast ass, et enthält e Verbindungszoustand - et kéint e L3 Balancer oder en aneren Service sinn. Da entsteet e Problem, well no RTO kënnt d'TCP Verbindung op de Server, deen näischt iwwer dës TCP Verbindung weess. A wa mir keng Staatsdeelung tëscht Anycast Serveren hunn, da gëtt esou Traffic erofgelooss an d'TCP-Verbindung gebrach.


Wat kënnt Dir hei maachen? Bannent Ärem kontrolléierten Ëmfeld, wou Dir Flow Label Balance aktivéiert, musst Dir de Wäert vum Flow Label notéieren wann Dir Zougang zu allcast Serveren hutt. Deen einfachste Wee ass dëst duerch dee selwechte eBPF Programm ze maachen. Awer hei ass e ganz wichtege Punkt - wat maache wann Dir net en Datenzenternetz bedreift, awer en Telekomoperateur ass? Dëst ass och Äre Problem: Start mat bestëmmte Versioune vu Juniper an Arista, si enthalen als Standard e Flow Label an hiren Hashfunktiounen - éierlech gesot, aus engem Grond dee mir net kloer ass. Dëst kann verursaachen datt Dir TCP Verbindunge vu Benotzer falen, déi duerch Äert Netzwierk passéieren. Also ech recommandéieren Är Router Astellungen hei ze kontrolléieren.

Eng Manéier oder aner, et schéngt mir, datt mir prett sinn op Experimenter ze plënneren.


Wéi mir de Flow Label op ToR aktivéiert hunn, den eBPF Agent virbereet, deen elo op de Hosten lieft, hu mir beschloss net op den nächste grousse Feeler ze waarden, awer kontrolléiert Explosiounen ze maachen. Mir hunn ToR geholl, dee véier Uplinks huet, an drop drop op ee vun hinnen opgeriicht. Si hunn eng Regel gezunn a gesot - elo verléiert Dir all Päck. Wéi Dir op der lénker Säit gesitt, hu mir Per-Packet-Iwwerwaachung, déi op 75% erofgaang ass, dat heescht, 25% vu Pakete ginn verluer. Riets sinn Grafike vu Servicer déi hannert dësem ToR liewen. Wesentlech sinn dës Traffic Grafike vun den Interfaces mat Serveren am Rack. Wéi Dir gesitt, sinn se nach méi niddereg gefall. Firwat si se méi niddereg erofgaang - net ëm 25%, awer an e puer Fäll ëm 3-4 Mol? Wann d'TCP Verbindung onglécklech ass, probéiert se weider duerch de gebrochenen Kräizung z'erreechen. Dëst gëtt verschäerft duerch dat typesch Verhalen vum Service am DC - fir eng Benotzerufro ginn N Ufroe fir intern Servicer generéiert, an d'Äntwert geet un de Benotzer entweder wann all Datenquellen äntweren, oder wann en Timeout bei der Applikatioun geschitt. Niveau, deen nach muss konfiguréiert ginn. Dat ass, alles ass ganz, ganz schlecht.


Elo datselwecht Experiment, awer mat dem Flow Label Wäert aktivéiert. Wéi Dir gesitt, ass op der lénker Säit eis Batch-Iwwerwaachung ëm déiselwecht 25% erofgaang. Dëst ass absolut korrekt, well et näischt iwwer d'Wiedertransmits weess, et schéckt Päckchen an zielt einfach d'Verhältnis vun der Unzuel vun geliwwert a verluerene Päckchen.

A riets ass de Service Zäitplang. Dir fannt den Effekt vun engem problematesche Gelenk hei net. An deene selwechte Millisekonnen ass de Verkéier aus dem Problemberäich op déi dräi verbleiwen Uplinks gefloss, déi net vum Problem betraff waren. Mir hunn en Netzwierk dat sech selwer heelt.

Dëst ass meng lescht Folie; Zäit fir ofzeschléissen. Elo hoffen ech, Dir wësst, wéi een e selbstheilend Datenzenternetz opbaut. Dir braucht net méi am Kernelarchiv ze gruewen. Linux A sicht do no spezielle Patches. Dir wësst, datt Flow Label de Problem an dësem Fall léist, awer Dir musst dëse Mechanismus mat Vorsicht ugoen. An ech betounen nach eng Kéier, datt Dir, wann Dir en Telekombetreiber sidd, Flow Label net als Hashfunktioun benotze sollt, soss stéiert Dir d'Sessiounen vun Äre Benotzer.

Netzwierkingenieuren mussen e konzeptuellen Verréckelung erliewen: d'Netzwierk fänkt net mam ToR un, net mam Netzwierkapparat, mee mam Host. E zimlech markant Beispill ass wéi mir eBPF benotzen souwuel fir den RTO z'änneren an de Flow Label Richtung Anycast Servicer ze fixéieren.

D'Flow Label Mechanik si sécher gëeegent fir aner Uwendungen am kontrolléiert administrativ Segment. Dëst kann Traffic tëscht Rechenzentren sinn, oder Dir kënnt esou Mechanik op eng speziell Manéier benotzen fir den ausginnen Traffic ze managen. Awer ech wäert Iech iwwer dëst soen, hoffen ech, d'nächst Kéier. Villmools Merci fir Är Opmierksamkeet.

Source: will.com