Moderne datacenters hebben honderden actieve apparaten die worden gedekt door verschillende soorten monitoring. Maar zelfs een perfecte engineer met perfecte monitoring in de hand zal in slechts enkele minuten kunnen reageren op een netwerkstoring. In een rapport op de Next Hop 2020-conferentie presenteerde ik een methodologie voor het ontwerpen van datacenternetwerken met een uniek kenmerk: het datacenter geneest zichzelf in milliseconden. Meer precies, de ingenieur lost het probleem rustig op, terwijl de services het gewoon niet opmerken.
Voor veel netwerkengineers begint het datacenternetwerk natuurlijk met ToR, met een switch in het rack. ToR heeft meestal twee soorten links. De kleintjes gaan naar de servers, anderen - er zijn er N keer meer - gaan naar de eerste niveau-ruggengraat, dat wil zeggen, naar de uplinks. Uplinks worden meestal als gelijk beschouwd en het verkeer tussen uplinks wordt gebalanceerd op basis van de 5-tuple hash, waaronder proto, src_ip, dst_ip, src_port, dst_port. Hier zijn geen verrassingen.
Hoe ziet de architectuur van de vliegtuigen er vervolgens uit? De stekels van het eerste level zijn niet met elkaar verbonden, maar zijn verbonden door middel van superspins. De letter X zal verantwoordelijk zijn voor superspins, het is bijna als een cross-connect.
En het is duidelijk dat tori daarentegen verbonden is met alle stekels van het eerste niveau. Wat is belangrijk op deze foto? Als we interactie hebben binnen het rek, dan gaat de interactie natuurlijk via ToR. Als de interactie binnen de module gaat, gaat de interactie door de ruggengraat van het eerste niveau. Als de interactie intermodulair is - zoals hier, ToR 1 en ToR 2 - dan zal de interactie door de ruggengraat van zowel het eerste als het tweede niveau gaan.
Theoretisch is zo'n architectuur eenvoudig schaalbaar. Als we poortcapaciteit hebben, een reserve aan ruimte in het datacenter en een pre-laid fiber, dan kan het aantal vliegtuigen altijd worden vergroot, waardoor de totale capaciteit van het systeem toeneemt. Op papier is dit heel gemakkelijk te doen. Zo zou het ook zijn in het echte leven. Maar daar gaat het verhaal van vandaag niet over.
Ik wil dat de juiste conclusies worden getrokken. We hebben veel paden in het datacenter. Ze zijn voorwaardelijk onafhankelijk. Eenrichtingsverkeer in het datacenter is alleen mogelijk binnen ToR. Binnen de module hebben we hetzelfde aantal paden als het aantal vlakken. Het aantal paden tussen modules is gelijk aan het product van het aantal vlakken en het aantal superspins in elk vlak. Om het duidelijker te maken, om de schaal te voelen, zal ik de cijfers geven die geldig zijn voor een van de Yandex-datacenters.
Er zijn acht vliegtuigen, elk vliegtuig heeft 32 superspins. Het resultaat is dat er acht paden in de module zijn, en met intermodule-interactie zijn dat er al 256.
Dat wil zeggen, als we een kookboek ontwikkelen en proberen te leren hoe we fouttolerante datacenters kunnen bouwen die zichzelf genezen, dan is de vlakke architectuur de juiste keuze. Hiermee kunt u het schaalprobleem oplossen, en in theorie is het eenvoudig. Er zijn veel onafhankelijke paden. De vraag blijft: hoe overleeft zo'n architectuur mislukkingen? Er zijn verschillende crashes. En daar gaan we het nu over hebben.
Laat een van onze superspins ziek worden. Hier keerde ik terug naar de architectuur van twee vlakken. We zullen ze als voorbeeld aanhouden, omdat het gewoon gemakkelijker zal zijn om te zien wat hier aan de hand is met minder bewegende delen. Laat X11 ziek worden. Welke invloed heeft dit op services die zich in datacenters bevinden? Veel hangt af van hoe de storing er daadwerkelijk uitziet.
Als de storing goed is, wordt deze opgevangen op het niveau van automatisering van dezelfde BFD, automatisering plaatst gelukkig probleemverbindingen en isoleert het probleem, dan is alles in orde. We hebben veel paden, verkeer wordt direct omgeleid naar alternatieve routes en de diensten merken er niets van. Dit is een goed scenario.
Een slecht scenario is als we constante verliezen hebben en de automatisering het probleem niet opmerkt. Om te begrijpen hoe dit de applicatie beïnvloedt, zullen we wat tijd moeten besteden aan het bespreken van hoe het TCP-protocol werkt.
Ik hoop dat ik niemand choqueer met deze informatie: TCP is een handshake-protocol. Dat wil zeggen, in het eenvoudigste geval verzendt de afzender twee pakketten en ontvangt daarop een cumulatieve bevestiging: "Ik heb twee pakketten ontvangen."
Daarna stuurt hij nog twee pakketten en herhaalt de situatie zich. Ik verontschuldig me bij voorbaat voor enige vereenvoudiging. Dit scenario is correct als het venster (aantal pakketten tijdens de vlucht) twee is. Uiteraard is dit in het algemeen niet noodzakelijk het geval. Maar de context voor het doorsturen van pakketten wordt niet beïnvloed door de venstergrootte.
Wat gebeurt er als we pakket 3 verliezen? In dit geval ontvangt de ontvanger pakketten 1, 2 en 4. En hij zal de afzender expliciet informeren met behulp van de SACK-optie: "Weet je, er zijn er drie gekomen, maar de middelste is verloren." Hij zegt "Ack 2, SACK 4".
De afzender herhaalt op dit moment precies het verloren pakket zonder problemen.
Maar als het laatste pakket in het venster verloren gaat, ziet de situatie er heel anders uit.
De ontvanger ontvangt de eerste drie pakketten en begint eerst te wachten. Dankzij enkele optimalisaties in de TCP-stack van de Linux-kernel, zal het wachten op een gepaard pakket, tenzij er een expliciete indicatie in de vlaggen is dat dit het laatste pakket is of iets dergelijks. Het zal wachten tot de Delayed ACK time-out afloopt en dan een bevestiging sturen voor de eerste drie pakketten. Maar nu wacht de afzender. Hij weet niet of het vierde pakket verloren is gegaan of op het punt staat aan te komen. En om het netwerk niet te overbelasten, zal het proberen te wachten op de expliciete indicatie dat het pakket verloren is, of het verstrijken van de RTO-time-out.
Wat is RTO-time-out? Dit is het maximum van de RTT berekend door de TCP-stack en een constante. Wat is deze constante, zullen we nu bespreken.
Maar het is belangrijk dat als we weer pech hebben en het vierde pakket weer verloren gaat, de RTO verdubbelt. Dat wil zeggen, elke mislukte poging is een verdubbeling van de time-out.
Laten we nu eens kijken waaraan deze basis gelijk is. Standaard is de minimale RTO 200 ms. Dit is de minimale RTO voor datapakketten. Voor SYN-pakketten is het anders, 1 seconde. Zoals u kunt zien, duurt zelfs de eerste poging om pakketten opnieuw te verzenden 100 keer langer dan RTT in het datacenter.
Nu terug naar ons scenario. Wat is er aan de hand met de dienst? De service begint pakketten te verliezen. Laat de service aanvankelijk geluk hebben en iets verliezen in het midden van het venster, dan ontvangt het een SACK, verzendt het de verloren pakketten opnieuw.
Maar als de pech zich herhaalt, dan hebben we een RTO. Wat is hier belangrijk? Ja, we hebben veel paden in het netwerk. Maar het TCP-verkeer van een bepaalde TCP-verbinding blijft via dezelfde kapotte stapel lopen. Pakketverlies, op voorwaarde dat onze magische X11 niet vanzelf uitgaat, leidt niet tot verkeer dat naar gebieden stroomt die niet problematisch zijn. We proberen een pakket af te leveren via dezelfde kapotte stapel. Dit leidt tot een trapsgewijze storing: een datacenter is een set van op elkaar inwerkende applicaties en sommige van de TCP-verbindingen van al deze applicaties beginnen te verslechteren - omdat de superspin van invloed is op alle applicaties die zich binnen het DC bevinden. Zoals in het gezegde: als je een paard niet beslaat, hinkt het paard; het paard hinkte - het rapport werd niet afgeleverd; het bericht is niet afgeleverd - ze hebben de oorlog verloren. Alleen hier telt het aantal seconden vanaf het moment dat het probleem zich voordoet tot het stadium van degradatie dat diensten beginnen te voelen. Dit betekent dat gebruikers mogelijk niet ergens iets ontvangen.
Er zijn twee klassieke oplossingen die elkaar aanvullen. De eerste zijn services die proberen strootjes te leggen en het probleem als volgt op te lossen: “Laten we iets in de TCP-stack aanpassen. En laten we time-outs op applicatieniveau of langdurige TCP-sessies maken met interne statuscontroles. Het probleem is dat dergelijke oplossingen: a) helemaal niet schaalbaar zijn; b) zeer slecht getest. Dat wil zeggen, zelfs als de service de TCP-stack per ongeluk zo configureert dat deze beter wordt, ten eerste is het onwaarschijnlijk dat dit van toepassing is op alle applicaties en alle datacenters, en ten tweede zal het hoogstwaarschijnlijk niet begrijpen wat correct is gedaan en wat niet. Dat wil zeggen, het werkt, maar het werkt slecht en schaalt niet. En als er een netwerkprobleem is, wie is dan de schuldige? Natuurlijk NOC. Wat doet NOC?
Veel diensten vinden dat werken in NOC ongeveer zo gaat. Maar om eerlijk te zijn, niet alleen.
NOC in het klassieke schema is bezig met de ontwikkeling van veel monitoring. Dit zijn zowel black box monitoring als white box monitoring. Over het voorbeeld van black box-monitoring van stekels Alexander Klimenko over het verleden Next Hop. Overigens werkt deze monitoring. Maar zelfs perfecte monitoring zal een vertraging hebben. Meestal is het enkele minuten. Nadat het werkt, hebben de dienstdoende ingenieurs tijd nodig om de werking ervan te controleren, het probleem te lokaliseren en vervolgens het probleemgebied te blussen. Dat wil zeggen, in het beste geval duurt de behandeling van het probleem 5 minuten, in het slechtste geval 20 minuten, als niet meteen duidelijk is waar de verliezen optreden. Het is duidelijk dat al die tijd - 5 of 20 minuten - onze diensten pijn zullen blijven doen, wat waarschijnlijk niet goed is.
Wat zou je graag willen ontvangen? We hebben zoveel wegen. En er ontstaan juist problemen doordat TCP-stromen die pech hebben dezelfde route blijven gebruiken. We hebben iets nodig waarmee we meerdere routes kunnen gebruiken binnen een enkele TCP-verbinding. Het lijkt erop dat we een oplossing hebben. Er is TCP, dat zo wordt genoemd - multipath TCP, dat wil zeggen TCP voor veel paden. Toegegeven, het is ontwikkeld voor een heel andere taak - voor smartphones met meerdere netwerkapparaten. Om de overdracht te maximaliseren of de primaire / back-upmodus te maken, is een mechanisme ontwikkeld dat op transparante wijze verschillende threads (sessies) voor de toepassing maakt en u in staat stelt om tussen deze te schakelen in geval van een storing. Of, zoals ik al zei, maximaliseer de bandbreedte.
Maar er is hier een nuance. Om te begrijpen wat het is, moeten we kijken hoe streams zijn opgezet.
Draden worden opeenvolgend ingesteld. De eerste stream wordt als eerste geïnstalleerd. Volgende stromen worden vervolgens ingesteld met behulp van de cookie die al binnen die thread is overeengekomen. En hier is het probleem.
Het probleem is dat als de eerste thread niet wordt geïnstalleerd, de tweede en derde thread nooit zullen verschijnen. Dat wil zeggen, multipath TCP lost het verlies van het SYN-pakket in de eerste stream niet op. En als de SYN verloren gaat, wordt multipath TCP normaal TCP. In een datacenteromgeving helpt het ons dus niet om het probleem van verliezen in de fabriek op te lossen en te leren hoe we meerdere paden kunnen gebruiken in geval van een storing.
Wat kan ons helpen? Sommigen van jullie hebben uit de naam al geraden dat het belangrijke veld in ons verdere verhaal het IPv6-stroomlabelkopveld zal zijn. Dit is inderdaad een veld dat verschijnt in v6, het is niet in v4, het duurt 20 bits, en er is lange tijd controverse geweest over het gebruik ervan. Dit is heel interessant - er waren geschillen, er werd iets opgelost in het kader van de RFC en tegelijkertijd verscheen er een implementatie in de Linux-kernel die nergens werd gedocumenteerd.
Ik stel voor dat je met me meegaat op een klein onderzoek. Laten we eens kijken wat er de afgelopen jaren in de Linux-kernel is gebeurd.
jaar 2014. Een ingenieur van een groot en gerenommeerd bedrijf voegt aan de functionaliteit van de Linux-kernel de afhankelijkheid toe van de waarde van het flowlabel van de hash van de socket. Wat proberen ze hier op te lossen? Dit houdt verband met RFC 6438 waarin het volgende probleem werd besproken. Binnen het datacenter is IPv4 vaak ingekapseld in IPv6-pakketten, omdat de fabriek zelf IPv6 is, maar IPv4 moet op de een of andere manier worden verspreid. Lange tijd waren er problemen met switches die niet onder twee IP-headers konden kijken om bij TCP of UDP te komen en daar src_ports, dst_ports te vinden. Het bleek dat de hash, als je naar de eerste twee IP-headers kijkt, bijna vast bleek te staan. Om dit te voorkomen, zodat het balanceren van dit ingekapselde verkeer correct werkt, werd voorgesteld om een hash van het 5-tuple ingekapselde pakket toe te voegen aan de waarde van het stroomlabelveld. Ongeveer hetzelfde werd gedaan voor andere inkapselingsschema's, voor UDP, voor GRE, in de laatste werd het GRE-sleutelveld gebruikt. Op de een of andere manier zijn de doelen hier duidelijk. En op dat moment waren ze tenminste nuttig.
In 2015 komt er een nieuwe patch van dezelfde gerespecteerde ingenieur. Hij is erg interessant. Er staat het volgende: we zullen de hash randomiseren in het geval van een negatieve routeringsgebeurtenis. Wat is een negatieve routeringsgebeurtenis? Dit is de RTO die we eerder hebben besproken, dat wil zeggen, het verlies van de vensterstaart is een gebeurtenis die echt negatief is. Toegegeven, het is relatief moeilijk te raden wat het is.
2016, weer een gerespecteerd bedrijf, ook groot. Het ontleedt de laatste krukken en zorgt ervoor dat de hash die we eerder willekeurig maakten, nu wordt gewijzigd bij elke SYN-heruitzending en na elke RTO-time-out. En in deze brief klinkt voor de eerste en laatste keer het ultieme doel: ervoor zorgen dat het verkeer bij verlies of overbelasting van kanalen de mogelijkheid heeft om zacht om te leiden, via meerdere paden. Natuurlijk, daarna waren er veel publicaties, je kunt ze gemakkelijk vinden.
Hoewel nee, dat kan niet, omdat er geen enkele publicatie over dit onderwerp is verschenen. Maar wij weten het!
En als je niet helemaal begrijpt wat er is gedaan, zal ik het je nu vertellen.
Wat is er gedaan, welke functionaliteit is toegevoegd aan de Linux-kernel? txhash verandert in een willekeurige waarde na elke RTO-gebeurtenis. Dit is hetzelfde negatieve routeringsresultaat. De hash is afhankelijk van deze txhash en het stroomlabel is afhankelijk van de skb-hash. Er zijn enkele berekeningen op de functies hier, alle details kunnen niet op één dia worden geplaatst. Als iemand nieuwsgierig is, kun je de kernelcode doornemen en controleren.
Wat is hier belangrijk? De waarde van het stroomlabelveld verandert na elke RTO in een willekeurig getal. Welke invloed heeft dit op onze ongelukkige TCP-stream?
In het geval van een SACK is er niets veranderd omdat we proberen een verloren pakket opnieuw te verzenden. Tot nu toe zo goed.
Maar in het geval van RTO, mits we een flowlabel hebben toegevoegd aan de hashfunctie op ToR, kan het verkeer een andere route nemen. En hoe meer vliegtuigen, hoe waarschijnlijker het is om een pad te vinden dat niet wordt beïnvloed door een crash op een bepaald apparaat.
Er blijft één probleem: RTO. Er wordt natuurlijk een andere route gevonden, maar er wordt veel tijd aan besteed. 200 ms is veel. Een tweede is over het algemeen wildheid. Eerder had ik het over time-outs die services configureren. Een seconde is dus een time-out die meestal een service op applicatieniveau opzet, en hierin zal de service zelfs relatief goed zijn. Bovendien, ik herhaal het, de echte RTT binnen een modern datacenter is ongeveer 1 milliseconde.
Wat kan er worden gedaan aan RTO-time-outs? De time-out die verantwoordelijk is voor RTO in geval van verlies van datapakketten kan relatief eenvoudig worden geconfigureerd vanuit de gebruikersruimte: er is een IP-hulpprogramma en een van de parameters ervan bevat dezelfde rto_min. Gezien het feit dat je RTO natuurlijk niet wereldwijd moet draaien, maar voor gegeven prefixen, lijkt zo'n mechanisme behoorlijk te werken.
Toegegeven, met SYN_RTO is alles iets erger. Het is van nature vastgespijkerd. De waarde ligt vast in de kern - 1 seconde, en dat is alles. Je kunt het niet bereiken vanuit de gebruikersruimte. Er is maar één manier.
eBPF schiet te hulp. Eenvoudig gezegd zijn dit kleine C-programma's, die op verschillende plaatsen in de uitvoering van de kernelstack en de TCP-stack in hooks kunnen worden ingevoegd, waarmee je een zeer groot aantal instellingen kunt wijzigen. Over het algemeen is eBPF een langetermijntrend. In plaats van tientallen nieuwe sysctl-parameters te zagen en het IP-hulpprogramma uit te breiden, is de beweging in de richting van eBPF en het uitbreiden van zijn functionaliteit. Met eBPF kunt u congestiecontroles en verschillende andere TCP-instellingen dynamisch wijzigen.
Maar het is belangrijk voor ons dat je met behulp hiervan de waarden van SYN_RTO kunt verdraaien. En er is een openbaar gepost voorbeeld: . Wat wordt hier gedaan? Het voorbeeld werkt, maar is op zichzelf erg ruw. Hier wordt aangenomen dat we in het datacenter de eerste 44 bits vergelijken, als ze overeenkomen, bevinden we ons in de DC. En in dit geval wijzigen we de waarde van de SYN_RTO-time-out in 4 ms. Dezelfde taak kan veel gracieus worden uitgevoerd. Maar dit eenvoudige voorbeeld laat zien wat a) mogelijk is; b) relatief eenvoudig.
Wat weten we al? Dat de planaire architectuur schaalvergroting mogelijk maakt, blijkt voor ons buitengewoon nuttig te zijn wanneer we het stroomlabel op ToR inschakelen en de mogelijkheid krijgen om probleemgebieden te omzeilen. De beste manier om RTO- en SYN-RTO-waarden te verlagen, is door eBPF-programma's te gebruiken. De vraag blijft: is het veilig om het flowlabel te gebruiken voor balanceren? En hier is een nuance.
Stel dat u een dienst op het netwerk heeft die in anycast leeft. Helaas heb ik geen tijd om in detail in te gaan op anycast, maar het is een gedistribueerde service waarbij verschillende fysieke servers beschikbaar zijn op hetzelfde IP-adres. En hier is een mogelijk probleem: de RTO-gebeurtenis kan niet alleen plaatsvinden wanneer verkeer door de fabriek gaat. Het kan ook optreden op het ToR-bufferniveau: wanneer een incast-gebeurtenis plaatsvindt, kan het zelfs op de host optreden wanneer de host iets morst. Wanneer een RTO-gebeurtenis optreedt en het stroomlabel verandert. In dit geval kan het verkeer naar een andere anycast-instantie gaan. Stel dat het een stateful anycast is, het bevat een verbindingsstatus - het kan een L3 Balancer zijn of een andere service. Dan ontstaat er een probleem, want na de RTO arriveert de TCP-verbinding bij de server, die niets weet van deze TCP-verbinding. En als we geen statusdeling hebben tussen anycast-servers, wordt dergelijk verkeer verbroken en wordt de TCP-verbinding verbroken.
Wat kan hier worden gedaan? Binnen uw gecontroleerde omgeving, waar u stroomlabelbalancering inschakelt, moet u de waarde van het stroomlabel vastleggen bij toegang tot anycast-servers. De gemakkelijkste manier is om het via hetzelfde eBPF-programma te doen. Maar hier is een heel belangrijk punt: wat te doen als u geen datacenternetwerk beheert, maar een telecomoperator bent? Dit is ook jouw probleem: te beginnen met bepaalde versies van Juniper en Arista, bevatten ze standaard het flow-label in de hash-functie - om eerlijk te zijn, begrijp ik het zonder reden. Dit kan ertoe leiden dat u TCP-verbindingen verbreekt van gebruikers die via uw netwerk gaan. Daarom raad ik u ten zeerste aan om uw routerinstellingen op deze locatie te controleren.
Op de een of andere manier lijkt het mij dat we klaar zijn om verder te gaan met experimenten.
Toen we het stroomlabel op ToR aanzetten, de eBPF van de agent voorbereidden, die nu op de hosts leeft, besloten we niet te wachten op de volgende grote storing, maar gecontroleerde explosies uit te voeren. We namen ToR, dat vier uplinks heeft, en dropten op een daarvan. Ze trokken een regel, zeiden ze - nu verlies je alle pakketten. Zoals je aan de linkerkant kunt zien, hebben we per pakket monitoring, die is gedaald tot 75%, dat wil zeggen dat 25% van de pakketten verloren gaat. Aan de rechterkant staan grafieken van diensten die achter deze ToR leven. In feite zijn dit verkeersgrafieken van verbindingen met servers in het rack. Zoals je kunt zien, zonken ze nog lager. Waarom zijn ze lager gezonken - niet met 25%, maar in sommige gevallen met 3-4 keer? Als de TCP-verbinding pech heeft, blijft deze proberen via de verbroken interface te bereiken. Dit wordt nog verergerd door het typische gedrag van de service binnen het DC - voor één gebruikersverzoek worden N verzoeken aan interne services gegenereerd en het antwoord gaat naar de gebruiker, hetzij wanneer alle gegevensbronnen reageren, hetzij wanneer een time-out wordt geactiveerd op het applicatieniveau, dat nog moet worden geconfigureerd. Dat wil zeggen, alles is heel erg slecht.
Nu hetzelfde experiment, maar met het stroomlabel ingeschakeld. Zoals u links kunt zien, zakte onze batchbewaking met dezelfde 25%. Dit is absoluut correct, want het weet niets van heruitzendingen, het verzendt pakketten en telt gewoon de verhouding tussen het aantal afgeleverde en verloren pakketten.
En aan de rechterkant is het schema van de diensten. Het effect van een probleemgewricht vind je hier niet. Verkeer stroomde in diezelfde milliseconden van het probleemgebied naar de drie resterende uplinks die niet door het probleem werden getroffen. We hebben een netwerk dat zichzelf geneest.
Dit is mijn laatste dia, tijd om de balans op te maken. Nu hoop ik dat je weet hoe je een zelfherstellend datacenternetwerk kunt bouwen. U hoeft niet door het Linux-kernelarchief te gaan en daar naar speciale patches te zoeken, u weet dat het Flow-label het probleem in dit geval oplost, maar u moet dit mechanisme voorzichtig benaderen. En ik benadruk nogmaals dat als je een drager bent, je het flow-label niet als hash-functie moet gebruiken, anders verbreek je de sessies van je gebruikers.
Voor netwerkingenieurs moet er een conceptuele verschuiving plaatsvinden: het netwerk begint niet met ToR, niet met een netwerkapparaat, maar met een host. Een redelijk treffend voorbeeld is hoe we eBPF gebruiken om zowel de RTO te wijzigen als om het flowlabel naar anycast-services te fixeren.
De flow label monteur is zeker geschikt voor andere toepassingen binnen het gecontroleerde administratieve segment. Dit kan verkeer tussen datacenters zijn, of u kunt dergelijke mechanismen op een speciale manier gebruiken om uitgaand verkeer te beheersen. Maar ik zal hier, hoop ik, de volgende keer over praten. Bedankt voor jullie aandacht.
Bron: www.habr.com