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 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 Päck an als éischt fänkt un ze waarden. Dank e puer Optimisatiounen am TCP-Stack vum Linux Kernel wäert et op e gepaart Paket waarden, ausser wann d'Fändelen explizit uginn datt et de leschte Paket ass oder eppes ähnleches. Et wäert waarden bis den Delayed ACK Timeout ofleeft a schéckt dann eng Unerkennung op déi éischt dräi Päck. Awer elo wäert de Sender waarden. Hie weess net ob de véierte Package verluer ass oder amgaang ass ze kommen. A fir d'Netzwierk net ze iwwerlaascht, probéiert et op eng explizit Indikatioun ze waarden datt de Paket verluer ass, oder datt de RTO-Timeout ofleeft.
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 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 hu scho vum Titel geroden datt e wichtegt Feld an eiser weiderer Geschicht den IPv6 Flow Label Header Feld wäert sinn. Tatsächlech ass dëst e Feld dat am v6 erschéngt, et ass net a v4, et besetzt 20 Bits, an et gouf Kontrovers iwwer seng Notzung fir eng laang Zäit. Dëst ass ganz interessant - et goufen Streidereien, eppes gouf am RFC fixéiert, a gläichzäiteg ass eng Implementatioun am Linux Kernel opgetaucht, déi néierens dokumentéiert gouf.
Ech invitéieren Iech mat mir op eng kleng Enquête ze goen. Loosst eis e Bléck op wat am Linux Kernel an de leschte Joren geschitt ass.
Joer 2014. En Ingenieur vun enger grousser a respektéierter Firma füügt d'Funktionalitéit vum Linux Kernel d'Ofhängegkeet vum Flow Label Wäert op de Socket Hash. Wat hu se probéiert hei ze fixéieren? Dëst ass am Zesummenhang mat RFC 6438, deen déi folgend Fro diskutéiert huet. Am Rechenzentrum ass IPv4 dacks an IPv6 Pakete verschlësselt, well d'Fabréck selwer IPv6 ass, awer IPv4 muss iergendwéi dobausse ginn. Fir eng laang Zäit waren et Probleemer mat Schalteren déi net ënner zwee IP-Header kucke konnten fir op TCP oder UDP ze kommen an do src_ports, dst_ports ze fannen. Et huet sech erausgestallt datt den Hash, wann Dir déi éischt zwee IP-Header kuckt, bal fixéiert ass. Fir dëst ze vermeiden, sou datt d'Balance vun dësem encapsuléierte Verkéier richteg funktionnéiert, gouf proposéiert den Hash vum 5-Tupel-encapsuléierte Paket op de Wäert vum Flow Labelfeld ze addéieren. Ongeféier déiselwecht Saach gouf fir aner Verschlësselungsschemae gemaach, fir UDP, fir GRE, déi lescht benotzt de GRE Key Feld. Op déi eng oder aner Manéier 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 zum Linux Kernel bäigefüügt? txhash Ännerungen zu engem zoufälleg Wäert no all RTO Event. Dëst ass dat ganz negativt Resultat vum Routing. Den Hash hänkt vun dësem Txhash of, an de Flowetikett hänkt vum skb Hash of. Et ginn e puer Berechnungen iwwer Funktiounen hei; all Detailer kënnen net op enger Rutsch gesat ginn. Wann iergendeen virwëtzeg ass, kënnt Dir duerch de Kernelcode goen 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: . 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 Rutsch, Zäit fir ze resuméieren. Elo, ech hoffen, datt Dir wësst wéi Dir e selbstheilenden Datenzenternetz bauen. Dir musst net duerch d'Linux Kernel Archiv goen an do no spezielle Patches sichen; Dir wësst datt de Flow Label an dësem Fall de Problem léist, awer Dir musst dëse Mechanismus suergfälteg ugoen. An ech ënnersträichen nach eng Kéier, datt wann Dir en Telekomoperateur sidd, Dir sollt de Flow-Label net als Hash-Funktioun benotzen, soss stéiert Dir Är Benotzersessiounen.
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