Moderna datacenter har hundratals aktiva enheter installerade, täckta av olika typer av övervakning. Men även en idealisk ingenjör med perfekt övervakning i handen kommer att kunna svara korrekt på ett nätverksfel på bara några minuter. I en rapport på Next Hop 2020-konferensen presenterade jag en metodik för design av datacenternätverk, som har en unik funktion – datacentret läker sig själv på millisekunder. Mer exakt, ingenjören löser problemet lugnt, medan tjänsterna helt enkelt inte märker det.
För många nätverksingenjörer börjar ett datacenternätverk förstås med ToR, med en switch i racket. ToR har vanligtvis två typer av länkar. De små går till servrarna, andra - det finns N gånger fler av dem - går mot ryggraden på den första nivån, det vill säga till dess upplänkar. Upplänkar anses vanligtvis vara lika, och trafik mellan upplänkar balanseras baserat på en hash från 5-tuple, som inkluderar proto, src_ip, dst_ip, src_port, dst_port. Inga överraskningar här.
Därefter, hur ser planarkitekturen ut? Ryggar på den första nivån är inte anslutna till varandra, utan är anslutna genom superryggar. Bokstaven X kommer att vara ansvarig för superspines; det är nästan som en korskoppling.
Och det är tydligt att å andra sidan tori är kopplade till alla ryggar på den första nivån. Vad är viktigt i den här bilden? Om vi har interaktion inne i racket, så går interaktionen förstås genom ToR. Om interaktionen sker inuti modulen, sker interaktionen genom ryggraden på första nivån. Om interaktionen är intermodulär - som här, ToR 1 och ToR 2 - kommer interaktionen att gå genom ryggraden på både den första och andra nivån.
I teorin är en sådan arkitektur lätt skalbar. Om vi har hamnkapacitet, ledigt utrymme i datacentret och förlagd fiber, så kan antalet körfält alltid utökas och därmed öka den totala kapaciteten i systemet. Detta är väldigt enkelt att göra på papper. Det skulle vara så här i livet. Men dagens historia handlar inte om det.
Jag vill att de rätta slutsatserna ska dras. Vi har många vägar inne i datacentret. De är villkorligt oberoende. En väg in i datacentret är endast möjlig inom ToR. Inuti modulen har vi antalet stigar lika med antalet körfält. Antalet vägar mellan moduler är lika med produkten av antalet plan och antalet superryggar i varje plan. För att göra det tydligare, för att få en känsla av skalan, kommer jag att ge siffror som är giltiga för ett av Yandex datacenter.
Det finns åtta plan, varje plan har 32 superryggar. Som ett resultat visar det sig att det finns åtta vägar inuti modulen, och med intermodulinteraktion finns det redan 256 av dem.
Det vill säga, om vi utvecklar Cookbook och försöker lära oss hur man bygger feltoleranta datacenter som läker sig själva, då är plan arkitektur det rätta valet. Det löser skalningsproblemet, och i teorin är det enkelt. Det finns många oberoende vägar. Frågan kvarstår: hur överlever en sådan arkitektur misslyckanden? Det finns olika misslyckanden. Och vi ska diskutera detta nu.
Låt en av våra superryggar "bli sjuk". Här återvände jag till tvåplansarkitekturen. Vi kommer att hålla oss till dessa som ett exempel eftersom det helt enkelt blir lättare att se vad som händer med färre rörliga delar. Låt X11 bli sjuk. Hur kommer detta att påverka tjänsterna som finns i datacenter? Mycket beror på hur misslyckandet faktiskt ser ut.
Om felet är bra, fångas det på automationsnivån för samma BFD, automatiken lägger glatt de problematiska lederna och isolerar problemet, då är allt bra. Vi har många vägar, trafiken omdirigeras omedelbart till alternativa vägar och tjänsterna kommer inte att märka något. Det här är ett bra manus.
Ett dåligt scenario är om vi har konstanta förluster, och automatiseringen inte märker problemet. För att förstå hur detta påverkar en applikation måste vi ägna lite tid åt att diskutera hur TCP fungerar.
Jag hoppas att jag inte chockerar någon med denna information: TCP är ett protokoll för överföringsbekräftelse. Det vill säga, i det enklaste fallet skickar avsändaren två paket och får ett kumulativt ack på dem: "Jag har tagit emot två paket."
Efter det kommer han att skicka ytterligare två paket, och situationen kommer att upprepas. Jag ber på förhand om ursäkt för en viss förenkling. Detta scenario är korrekt om fönstret (antalet paket under flygning) är två. Naturligtvis är detta inte nödvändigtvis fallet i det allmänna fallet. Men fönsterstorleken påverkar inte kontexten för vidarebefordran av paket.
Vad händer om vi tappar paket 3? I det här fallet kommer mottagaren att ta emot paket 1, 2 och 4. Och han kommer uttryckligen att säga till avsändaren med SACK-alternativet: "Du vet, tre kom, men mitten gick förlorad." Han säger: "Ack 2, SACK 4."
I detta ögonblick upprepar avsändaren utan problem exakt det paket som gick förlorat.
Men om det sista paketet i fönstret går förlorat kommer situationen att se helt annorlunda ut.
Mottagaren tar emot de tre första paketen och börjar först och främst vänta. Tack vare vissa optimeringar i Linux-kärnans TCP-stack kommer den att vänta på ett parat paket om inte flaggorna uttryckligen indikerar att det är det sista paketet eller något liknande. Den kommer att vänta tills den fördröjda ACK-timeouten löper ut och skickar sedan en bekräftelse på de tre första paketen. Men nu väntar avsändaren. Han vet inte om det fjärde paketet har gått förlorat eller är på väg att anlända. Och för att inte överbelasta nätverket kommer det att försöka vänta på en uttrycklig indikation på att paketet är förlorat, eller på att RTO-timeouten löper ut.
Vad är RTO-timeout? Detta är maximivärdet för RTT beräknat av TCP-stacken och någon konstant. Vilken typ av konstant detta är ska vi nu diskutera.
Men det viktiga är att om vi har otur igen och det fjärde paketet går förlorat igen, så fördubblas RTO:n. Det vill säga att varje misslyckat försök innebär att timeouten fördubblas.
Låt oss nu se vad denna bas är lika med. Som standard är minsta RTO 200 ms. Detta är den lägsta RTO för datapaket. För SYN-paket är det annorlunda, 1 sekund. Som du kan se kommer även det första försöket att skicka om paket ta 100 gånger längre tid än RTT inuti datacentret.
Låt oss nu gå tillbaka till vårt scenario. Vad händer med tjänsten? Tjänsten börjar tappa paket. Låt tjänsten först ha villkorlig tur och förlora något i mitten av fönstret, sedan får den en SACK och skickar om paketen som gick förlorade.
Men om oturen upprepar sig, då har vi en RTO. Vad är viktigt här? Ja, vi har många vägar i vårt nätverk. Men TCP-trafiken för en viss TCP-anslutning kommer att fortsätta att gå igenom samma trasiga stack. Paketförluster, förutsatt att denna magiska X11 av oss inte slocknar av sig själv, leder inte till att trafik flyter in i områden som inte är problematiska. Vi försöker leverera paketet genom samma trasiga stack. Detta leder till ett kaskadfel: ett datacenter är en uppsättning interagerande applikationer, och några av TCP-anslutningarna för alla dessa applikationer börjar försämras - eftersom superspine påverkar alla applikationer som finns inuti datacentret. Som ordspråket säger: om du inte skode en häst, blev hästen halt; hästen blev halt - rapporten levererades inte; rapporten levererades inte - vi förlorade kriget. Endast här räknas räkningen i sekunder från det ögonblick problemet uppstår till det stadium av nedbrytning som tjänsterna börjar kännas. Det betyder att användare kan gå miste om något någonstans.
Det finns två klassiska lösningar som kompletterar varandra. Den första är tjänster som försöker lägga sugrör i och lösa problemet så här: "Låt oss justera något i TCP-stacken. Låt oss göra timeouts på applikationsnivå eller långlivade TCP-sessioner med interna hälsokontroller." Problemet är att sådana lösningar: a) inte skalas alls; b) är mycket dåligt kontrollerade. Det vill säga, även om tjänsten av misstag konfigurerar TCP-stacken på ett sätt som gör den bättre, för det första är det osannolikt att det är tillämpligt för alla applikationer och alla datacenter, och för det andra kommer den troligen inte att förstå att det gjordes korrekt, och vad inte. Det vill säga det fungerar, men det fungerar dåligt och skalar inte. Och om det finns ett nätverksproblem, vem är skyldig? Naturligtvis NOC. Vad gör NOC?
Många tjänster tror att i NOC-arbete händer något liknande detta. Men för att vara ärlig, inte bara det.
NOC i det klassiska systemet är engagerad i utvecklingen av många övervakningssystem. Dessa är både black box och white box övervakning. Om ett exempel på black box ryggradsövervakning Alexander Klimenko vid sista nästa hopp. Den här övervakningen fungerar förresten. Men även idealisk övervakning kommer att ha en tidsfördröjning. Vanligtvis är detta några minuter. Efter att den har slocknat behöver tjänstgörande ingenjörer tid för att dubbelkontrollera dess funktion, lokalisera problemet och sedan släcka problemområdet. Det vill säga att i bästa fall tar behandling av problemet 5 minuter, i värsta fall 20 minuter, om det inte direkt är uppenbart var förlusterna sker. Det är uppenbart att hela denna tid - 5 eller 20 minuter - kommer våra tjänster att fortsätta att lida, vilket förmodligen inte är bra.
Vad skulle du verkligen vilja få? Vi har så många sätt. Och problem uppstår just för att TCP-flöden som har otur fortsätter att använda samma väg. Vi behöver något som gör att vi kan använda flera rutter inom en enda TCP-anslutning. Det verkar som att vi har en lösning. Det finns TCP, som kallas multipath TCP, det vill säga TCP för flera vägar. Det är sant att det utvecklades för en helt annan uppgift - för smartphones som har flera nätverksenheter. För att maximera överföring eller göra primärt/säkerhetskopieringsläge utvecklades en mekanism som skapar flera trådar (sessioner) transparent för applikationen och låter dig växla mellan dem i händelse av ett fel. Eller, som sagt, maximera streaken.
Men det finns en nyans här. För att förstå vad det är måste vi titta på hur trådar upprättas.
Trådar installeras sekventiellt. Den första tråden installeras först. Efterföljande trådar sätts sedan med hjälp av den cookie som redan har avtalats inom den tråden. Och här är problemet.
Problemet är att om den första tråden inte etablerar sig, kommer den andra och tredje tråden aldrig att uppstå. Det vill säga flervägs-TCP löser inte förlusten av ett SYN-paket i det första flödet. Och om SYN går förlorad, förvandlas flervägs TCP till vanlig TCP. Det betyder att i en datacentermiljö kommer det inte att hjälpa oss att lösa problemet med förluster i fabriken och lära oss att använda flera vägar i händelse av ett fel.
Vad kan hjälpa oss? Några av er har redan gissat från titeln att ett viktigt fält i vår fortsatta berättelse kommer att vara rubrikfältet för IPv6-flödesetiketter. Det här är faktiskt ett fält som visas i v6, det är inte i v4, det upptar 20 bitar och det har varit kontroverser om dess användning under lång tid. Detta är väldigt intressant - det fanns dispyter, något fixades inom RFC, och samtidigt dök en implementering upp i Linux-kärnan, som inte dokumenterades någonstans.
Jag inbjuder dig att följa med mig på en liten utredning. Låt oss ta en titt på vad som har hänt i Linux-kärnan under de senaste åren.
år 2014. En ingenjör från ett stort och respekterat företag lägger till funktionaliteten hos Linuxkärnan beroendet av flödesetikettvärdet på socket-hashen. Vad försökte de fixa här? Detta är relaterat till RFC 6438, som diskuterade följande fråga. Inuti datacentret är IPv4 ofta inkapslat i IPv6-paket, eftersom själva fabriken är IPv6, men IPv4 måste på något sätt ges utanför. Länge var det problem med switchar som inte kunde leta under två IP-rubriker för att komma till TCP eller UDP och hitta src_ports, dst_ports där. Det visade sig att hashen, om man tittar på de två första IP-huvudena, visade sig vara nästan fixad. För att undvika detta, så att balanseringen av denna inkapslade trafik fungerar korrekt, föreslogs det att lägga till hashen för det 5-tupels inkapslade paketet till värdet av flödesetikettfältet. Ungefär samma sak gjordes för andra inkapslingsscheman, för UDP, för GRE, den senare använde GRE Key-fältet. På ett eller annat sätt är målen här tydliga. Och åtminstone vid den tidpunkten var de användbara.
2015 kommer en ny patch från samma respekterade ingenjör. Han är väldigt intressant. Det står följande - vi kommer att randomisera hashen i händelse av en negativ routinghändelse. Vad är en negativ routinghändelse? Detta är den RTO som vi diskuterade tidigare, det vill säga att förlusten av fönstrets svans är en händelse som verkligen är negativ. Det är sant att det är relativt svårt att gissa att det är så.
2016, ett annat välrenommerat företag, också stort. Den plockar isär de sista kryckorna och gör det så att hashen, som vi tidigare gjorde slumpmässigt, nu ändras för varje SYN-omsändning och efter varje RTO-timeout. Och i det här brevet, för första och sista gången, anges det slutliga målet - att säkerställa att trafik i händelse av förluster eller kanalstockningar har förmågan att mjukt omdirigeras och använda flera vägar. Naturligtvis, efter detta fanns det många publikationer, du kan lätt hitta dem.
Fast nej, det kan du inte, för det har inte funnits en enda publikation om detta ämne. Men vi vet!
Och om du inte helt förstår vad som gjordes, ska jag berätta det nu.
Vad gjordes, vilken funktion lades till i Linux-kärnan? txhash ändras till ett slumpmässigt värde efter varje RTO-händelse. Detta är det mycket negativa resultatet av routing. Hashen beror på denna txhash, och flödesetiketten beror på skb-hash. Det finns några beräkningar på funktioner här, alla detaljer kan inte placeras på en bild. Om någon är nyfiken kan du gå igenom kärnkoden och kolla.
Vad är viktigt här? Värdet på flödesetikettfältet ändras till ett slumpmässigt tal efter varje RTO. Hur påverkar detta vår olyckliga TCP-ström?
Om en SACK inträffar ändras ingenting eftersom vi försöker skicka om ett känt förlorat paket. Än så länge är allt bra.
Men i fallet med RTO, förutsatt att vi har lagt till en flödesetikett till hashfunktionen på ToR, kan trafiken ta en annan väg. Och ju fler körfält, desto större är chansen att den hittar en väg som inte påverkas av ett fel på en viss enhet.
Ett problem kvarstår - RTO. Naturligtvis finns det en annan väg, men mycket tid slösas bort på detta. 200 ms är mycket. En sekund är helt vild. Tidigare har jag pratat om timeouts som tjänster konfigureras. Så, en andra är en timeout, som vanligtvis konfigureras av tjänsten på applikationsnivå, och i detta kommer tjänsten till och med att vara relativt rätt. Dessutom, jag upprepar, den verkliga RTT i ett modernt datacenter är cirka 1 millisekund.
Vad kan du göra med RTO-timeouts? Timeouten, som är ansvarig för RTO vid förlust av datapaket, kan konfigureras relativt enkelt från användarutrymmet: det finns ett IP-verktyg och en av dess parametrar innehåller samma rto_min. Med tanke på att RTO naturligtvis inte behöver justeras globalt, utan för givna prefix, ser en sådan mekanism ganska fungerande ut.
Det är sant, med SYN_RTO är allt något värre. Det är naturligt spikat. Kärnan har ett fast värde på 1 sekund, och det är allt. Du kan inte nå dit från användarutrymmet. Det finns bara ett sätt.
eBPF kommer till undsättning. Enkelt uttryckt är det små C-program De kan infogas i hooks på olika ställen i exekveringen av kärnstacken och TCP-stacken, med vilka man kan ändra ett väldigt stort antal inställningar. Generellt sett är eBPF en långsiktig trend. Istället för att klippa dussintals nya sysctl-parametrar och utöka IP-verktyget, går rörelsen mot eBPF och utökar dess funktionalitet. Med eBPF kan du dynamiskt ändra trafikstockningskontroller och olika andra TCP-inställningar.
Men det är viktigt för oss att det kan användas för att ändra SYN_RTO-värdena. Dessutom finns det ett offentligt publicerat exempel: . Vad har gjorts här? Exemplet fungerar, men är i sig väldigt grovt. Här antas det att vi inuti datacentret jämför de första 44 bitarna, om de matchar så är vi inne i datacentret. Och i det här fallet ändrar vi SYN_RTO timeout-värdet till 4ms. Samma uppgift kan göras mycket mer elegant. Men detta enkla exempel visar att detta är a) möjligt; b) relativt enkelt.
Vad vet vi redan? Det faktum att planarkitekturen tillåter skalning, det visar sig vara oerhört användbart för oss när vi aktiverar flödesetiketten på ToR och får möjlighet att flyta runt problemområden. Det bästa sättet att minska RTO- och SYN-RTO-värdena är att använda eBPF-program. Frågan kvarstår: är det säkert att använda en flödesetikett för balansering? Och det finns en nyans här.
Anta att du har en tjänst i ditt nätverk som finns i anycast. Tyvärr har jag inte tid att gå in på detaljer om vad anycast är, utan det är en distribuerad tjänst med olika fysiska servrar tillgängliga via samma IP-adress. Och här är ett möjligt problem: RTO-händelsen kan inträffa inte bara när trafik passerar genom tyget. Det kan också inträffa på ToR-buffertnivån: när en incast-händelse inträffar kan det till och med inträffa på värden när värden spiller något. När en RTO-händelse inträffar och den ändrar flödesetiketten. I det här fallet kan trafiken gå till en annan anycast-instans. Låt oss anta att detta är en stateful anycast, den innehåller ett anslutningstillstånd - det kan vara en L3 Balancer eller någon annan tjänst. Då uppstår ett problem, för efter RTO kommer TCP-anslutningen till servern, som inte vet något om denna TCP-förbindelse. Och om vi inte har tillståndsdelning mellan anycast-servrar, kommer sådan trafik att släppas och TCP-anslutningen kommer att brytas.
Vad kan du göra här? Inom din kontrollerade miljö, där du aktiverar flödesetikettbalansering, måste du registrera värdet på flödesetiketten när du kommer åt anycast-servrar. Det enklaste sättet är att göra detta genom samma eBPF-program. Men här är en mycket viktig punkt - vad ska du göra om du inte driver ett datacenternätverk, men är en telekomoperatör? Det här är ditt problem också: från och med vissa versioner av Juniper och Arista inkluderar de en flödesetikett i sina hashfunktioner som standard - ärligt talat, av en anledning som är otydlig för mig. Detta kan göra att du avbryter TCP-anslutningar från användare som passerar ditt nätverk. Så jag rekommenderar starkt att du kontrollerar din routers inställningar här.
På ett eller annat sätt verkar det för mig att vi är redo att gå vidare till experiment.
När vi aktiverade flödesetiketten på ToR, förberedde eBPF-agenten, som nu lever på värdarna, bestämde vi oss för att inte vänta på nästa stora misslyckande, utan att genomföra kontrollerade explosioner. Vi tog ToR, som har fyra upplänkar, och satte upp drops på en av dem. De drog en regel och sa - nu tappar du alla paket. Som du kan se till vänster har vi övervakning per paket, som har sjunkit till 75%, det vill säga 25% av paketen går förlorade. Till höger finns grafer över tjänster som lever bakom denna ToR. I huvudsak är dessa trafikdiagram över gränssnitten med servrar inuti racket. Som ni ser sjönk de ännu lägre. Varför sjönk de lägre - inte med 25%, men i vissa fall med 3-4 gånger? Om TCP-anslutningen har otur fortsätter den att försöka nå genom den trasiga korsningen. Detta förvärras av tjänstens typiska beteende inuti DC - för en användarförfrågan genereras N förfrågningar till interna tjänster, och svaret kommer att gå till användaren antingen när alla datakällor svarar eller när en timeout inträffar i applikationen nivå, som fortfarande behöver konfigureras. Det vill säga allt är väldigt, väldigt dåligt.
Nu samma experiment, men med flödesetikettvärdet aktiverat. Som du kan se, till vänster sjönk vår batchövervakning med samma 25%. Detta är helt korrekt, eftersom den inte kan något om återsändningar, den skickar paket och räknar helt enkelt förhållandet mellan antalet levererade och förlorade paket.
Och till höger är serviceschemat. Du hittar inte effekten av en problematisk fog här. På samma millisekunder flödade trafik från problemområdet till de tre återstående upplänkarna som inte påverkades av problemet. Vi har ett nätverk som läker sig själv.
Detta är min sista bild, dags att sammanfatta. Nu hoppas jag att du vet hur man bygger ett självläkande datacenternätverk. Du behöver inte gå igenom Linux-kärnarkivet och leta efter speciella patchar där; du vet att Flow-etiketten i det här fallet löser problemet, men du måste närma dig den här mekanismen noggrant. Och jag understryker än en gång att om du är teleoperatör så ska du inte använda flödesetikett som hashfunktion, annars kommer du att störa dina användares sessioner.
Nätverksingenjörer måste genomgå ett konceptuellt skifte: nätverket börjar inte med ToR, inte med nätverksenheten, utan med värden. Ett ganska slående exempel är hur vi använder eBPF både för att ändra RTO och för att fixa flödesetiketten mot anycast-tjänster.
Flödesetikettmekaniken lämpar sig säkert för andra applikationer inom det kontrollerade administrativa segmentet. Det kan vara trafik mellan datacenter, eller så kan man använda sådan mekanik på ett speciellt sätt för att hantera utgående trafik. Men jag ska berätta om det här, hoppas jag, nästa gång. Tack så mycket för din uppmärksamhet.
Källa: will.com