Moderne datacentre har hundredvis af aktive enheder installeret, dækket af forskellige typer overvågning. Men selv en ideel ingeniør med perfekt overvågning i hånden vil være i stand til at reagere korrekt på en netværksfejl på kun få minutter. I en rapport på Next Hop 2020-konferencen præsenterede jeg en datacenternetværksdesignmetodologi, som har en unik funktion - datacentret helbreder sig selv på millisekunder. Mere præcist løser ingeniøren roligt problemet, mens tjenesterne simpelthen ikke bemærker det.
For mange netværksingeniører begynder et datacenternetværk naturligvis med ToR, med en switch i stativet. ToR har normalt to typer links. De små går til serverne, andre - der er N gange flere af dem - går mod ryggen på det første niveau, det vil sige til dets uplinks. Uplinks betragtes normalt som ligeværdige, og trafik mellem uplinks er afbalanceret baseret på en hash fra 5-tuple, som inkluderer proto, src_ip, dst_ip, src_port, dst_port. Ingen overraskelser her.
Dernæst, hvordan ser planarkitekturen ud? Spines på det første niveau er ikke forbundet med hinanden, men er forbundet gennem superspines. Bogstavet X vil være ansvarlig for superspines; det er næsten som en krydsforbindelse.
Og det er klart, at på den anden side er tori forbundet med alle rygsøjler på det første niveau. Hvad er vigtigt på dette billede? Hvis vi har interaktion inde i stativet, så går interaktionen selvfølgelig gennem ToR. Hvis interaktionen finder sted inde i modulet, så sker interaktionen gennem rygraderne på første niveau. Hvis interaktionen er intermodulær - som her, ToR 1 og ToR 2 - så vil interaktionen gå gennem spines på både første og andet niveau.
I teorien er sådan en arkitektur let skalerbar. Hvis vi har havnekapacitet, ledig plads i datacenteret og forudlagt fiber, så kan antallet af baner altid øges og dermed øge den samlede kapacitet i systemet. Dette er meget nemt at gøre på papiret. Sådan ville det være i livet. Men det handler dagens historie ikke om.
Jeg vil gerne drage de rigtige konklusioner. Vi har mange veje inde i datacentret. De er betinget uafhængige. Én sti inde i datacentret er kun mulig inde i ToR. Inde i modulet har vi antallet af stier svarende til antallet af baner. Antallet af stier mellem moduler er lig med produktet af antallet af planer og antallet af superspines i hvert plan. For at gøre det tydeligere, for at få en fornemmelse af skalaen, vil jeg give tal, der er gyldige for et af Yandex-datacentrene.
Der er otte fly, hvert fly har 32 superrygsøjler. Som et resultat viser det sig, at der er otte stier inde i modulet, og med intermodulinteraktion er der allerede 256 af dem.
Det vil sige, at hvis vi udvikler Cookbook og prøver at lære at bygge fejltolerante datacentre, der helbreder sig selv, så er plan arkitektur det rigtige valg. Det løser skaleringsproblemet, og i teorien er det nemt. Der er mange selvstændige veje. Tilbage står spørgsmålet: hvordan overlever sådan en arkitektur fiaskoer? Der er forskellige fejl. Og det vil vi diskutere nu.
Lad en af vores superrygsøjler "blive syg". Her vendte jeg tilbage til toplansarkitekturen. Vi holder os til disse som et eksempel, fordi det simpelthen bliver nemmere at se, hvad der sker med færre bevægelige dele. Lad X11 blive syg. Hvordan vil dette påvirke de tjenester, der lever inde i datacentre? Meget afhænger af, hvordan fiaskoen rent faktisk ser ud.
Hvis fejlen er god, fanges den på automatiseringsniveauet af samme BFD, automatikken sætter gladeligt de problematiske led og isolerer problemet, så er alt i orden. Vi har mange stier, trafikken omdirigeres øjeblikkeligt til alternative ruter, og tjenester vil ikke bemærke noget. Dette er et godt manuskript.
Et dårligt scenarie er, hvis vi har konstante tab, og automatiseringen ikke opdager problemet. For at forstå, hvordan dette påvirker en applikation, bliver vi nødt til at bruge lidt tid på at diskutere, hvordan TCP virker.
Jeg håber ikke, at jeg chokerer nogen med denne information: TCP er en transmissionsbekræftelsesprotokol. Det vil sige, i det enkleste tilfælde sender afsenderen to pakker og modtager en kumulativ ack på dem: "Jeg har modtaget to pakker."
Derefter vil han sende to pakker mere, og situationen vil gentage sig. Jeg undskylder på forhånd for en vis forenkling. Dette scenarie er korrekt, hvis vinduet (antallet af pakker under flyvning) er to. I det generelle tilfælde er dette naturligvis ikke nødvendigvis tilfældet. Men vinduesstørrelsen påvirker ikke pakkevideresendelseskonteksten.
Hvad sker der, hvis vi mister pakke 3? I dette tilfælde vil modtageren modtage pakke 1, 2 og 4. Og han vil udtrykkeligt fortælle afsenderen ved at bruge SACK-muligheden: "Du ved, tre ankom, men midten var tabt." Han siger: "Ack 2, SACK 4."
I dette øjeblik gentager afsenderen uden problemer præcis den pakke, der gik tabt.
Men hvis den sidste pakke i vinduet går tabt, vil situationen se helt anderledes ud.
Modtageren modtager de første tre pakker og begynder først og fremmest at vente. Takket være nogle optimeringer i Linux-kernens TCP-stak, vil den vente på en parret pakke, medmindre flagene udtrykkeligt angiver, at det er den sidste pakke eller noget lignende. Den vil vente, indtil den forsinkede ACK-timeout udløber, og derefter sende en bekræftelse på de første tre pakker. Men nu vil afsenderen vente. Han ved ikke, om den fjerde pakke er gået tabt eller er ved at ankomme. Og for ikke at overbelaste netværket, vil det forsøge at vente på en eksplicit indikation af, at pakken er tabt, eller på at RTO-timeoutet udløber.
Hvad er RTO timeout? Dette er maksimum af RTT beregnet af TCP-stakken og en vis konstant. Hvilken slags konstant dette er, vil vi nu diskutere.
Men det vigtige er, at hvis vi er uheldige igen, og den fjerde pakke går tabt igen, så fordobles RTO'en. Det vil sige, at hvert mislykket forsøg betyder en fordobling af timeout.
Lad os nu se, hvad denne base er lig med. Som standard er minimum RTO 200 ms. Dette er minimums-RTO for datapakker. For SYN-pakker er det anderledes, 1 sekund. Som du kan se, vil selv det første forsøg på at gensende pakker tage 100 gange længere tid end RTT inde i datacentret.
Lad os nu vende tilbage til vores scenarie. Hvad sker der med tjenesten? Tjenesten begynder at miste pakker. Lad tjenesten først være betinget heldig og miste noget midt i vinduet, så modtager den en SACK og sender de pakker, der gik tabt igen.
Men hvis uheldet gentager sig, så har vi en RTO. Hvad er vigtigt her? Ja, vi har mange veje i vores netværk. Men TCP-trafikken for en bestemt TCP-forbindelse vil fortsætte med at gå gennem den samme ødelagte stak. Pakketab, forudsat at vores magiske X11 ikke går ud af sig selv, fører ikke til, at trafik flyder ind i områder, der ikke er problematiske. Vi forsøger at levere pakken gennem den samme ødelagte stak. Dette fører til en kaskadefejl: et datacenter er et sæt interagerende applikationer, og nogle af TCP-forbindelserne i alle disse applikationer begynder at blive forringet - fordi superspine påvirker alle applikationer, der findes inde i datacentret. Som man siger: Hvis du ikke skoede en hest, blev hesten halt; hesten blev halt - rapporten blev ikke leveret; rapporten blev ikke leveret - vi tabte krigen. Kun her er tællingen i sekunder fra det øjeblik, problemet opstår til det stadium af nedbrydning, som tjenesterne begynder at føle. Det betyder, at brugerne kan gå glip af noget et eller andet sted.
Der er to klassiske løsninger, der supplerer hinanden. Den første er tjenester, der forsøger at putte sugerør i og løse problemet sådan her: "Lad os justere noget i TCP-stakken. Lad os lave timeouts på applikationsniveau eller langvarige TCP-sessioner med interne sundhedstjek." Problemet er, at sådanne løsninger: a) slet ikke skaleres; b) er meget dårligt kontrolleret. Det vil sige, at selvom tjenesten ved et uheld konfigurerer TCP-stakken på en måde, der gør den bedre, for det første er det usandsynligt, at det vil være anvendeligt for alle applikationer og alle datacentre, og for det andet vil den højst sandsynligt ikke forstå, at det blev gjort korrekt, og hvad ikke. Det vil sige, det virker, men det fungerer dårligt og skalerer ikke. Og hvis der er et netværksproblem, hvem er så skylden? Selvfølgelig NOC. Hvad laver NOC?
Mange tjenester mener, at der i NOC-arbejde sker noget som dette. Men for at være ærlig, ikke kun det.
NOC i den klassiske ordning er engageret i udviklingen af mange overvågningssystemer. Disse er både black box og white box overvågning. Om et eksempel på black box-rygsøjleovervågning Alexander Klimenko ved det sidste Next Hop. I øvrigt virker denne overvågning. Men selv ideel overvågning vil have en tidsforsinkelse. Normalt er dette et par minutter. Efter at den er slukket, har ingeniørerne på vagt brug for tid til at dobbelttjekke dens funktion, lokalisere problemet og derefter slukke problemområdet. Det vil sige, at behandling af problemet i bedste fald tager 5 minutter, i værste fald 20 minutter, hvis det ikke umiddelbart er tydeligt, hvor tabene opstår. Det er klart, at hele denne tid - 5 eller 20 minutter - vil vores tjenester fortsat lide, hvilket sandsynligvis ikke er godt.
Hvad vil du egentlig gerne modtage? Vi har så mange måder. Og problemer opstår netop, fordi TCP-flows, der er uheldige, fortsætter med at bruge samme rute. Vi har brug for noget, der giver os mulighed for at bruge flere ruter inden for en enkelt TCP-forbindelse. Det ser ud til, at vi har en løsning. Der er TCP, som kaldes multipath TCP, det vil sige TCP for flere stier. Sandt nok blev den udviklet til en helt anden opgave - til smartphones, der har flere netværksenheder. For at maksimere overførsel eller lave primær/backup-tilstand blev der udviklet en mekanisme, der skaber flere tråde (sessioner) gennemsigtigt for applikationen og giver dig mulighed for at skifte mellem dem i tilfælde af en fejl. Eller, som sagt, maksimere streaken.
Men der er en nuance her. For at forstå, hvad det er, bliver vi nødt til at se på, hvordan tråde etableres.
Tråde installeres sekventielt. Den første tråd monteres først. Efterfølgende tråde sættes derefter ved hjælp af den cookie, der allerede er aftalt i den tråd. Og her er problemet.
Problemet er, at hvis den første tråd ikke etablerer sig, vil den anden og tredje tråd aldrig opstå. Det vil sige, multipath TCP løser ikke tabet af en SYN-pakke i det første flow. Og hvis SYN går tabt, bliver multipath TCP til almindelig TCP. Det betyder, at det i et datacentermiljø ikke hjælper os med at løse problemet med tab på fabrikken og lære at bruge flere stier i tilfælde af en fejl.
Hvad kan hjælpe os? Nogle af jer har allerede gættet ud fra titlen, at et vigtigt felt i vores videre historie vil være IPv6 flow label header-feltet. Faktisk er dette et felt, der vises i v6, det er ikke i v4, det optager 20 bit, og der har været uenighed om dets brug i lang tid. Dette er meget interessant - der var uenigheder, noget blev rettet i RFC'en, og samtidig dukkede en implementering op i Linux-kernen, som ikke var dokumenteret nogen steder.
Jeg inviterer dig til at tage med mig på en lille undersøgelse. Lad os tage et kig på, hvad der er sket i Linux-kernen i løbet af de sidste par år.
år 2014. En ingeniør fra en stor og respekteret virksomhed tilføjer til Linux-kernens funktionalitet afhængigheden af flowetiketværdien af socket-hashen. Hvad prøvede de at ordne her? Dette er relateret til RFC 6438, som diskuterede følgende problem. Inde i datacentret er IPv4 ofte indkapslet i IPv6-pakker, fordi selve fabrikken er IPv6, men IPv4 skal på en eller anden måde gives udenfor. I lang tid var der problemer med switches, der ikke kunne se under to IP-headere for at komme til TCP eller UDP og finde src_ports, dst_ports der. Det viste sig, at hashen, hvis man ser på de to første IP-headere, viste sig at være næsten rettet. For at undgå dette, så afbalanceringen af denne indkapslede trafik fungerer korrekt, blev det foreslået at tilføje hashen af den 5-tuple indkapslede pakke til værdien af flowetiketfeltet. Omtrent det samme blev gjort for andre indkapslingsskemaer, for UDP, for GRE, sidstnævnte brugte GRE Key-feltet. På en eller anden måde er målene her klare. Og i det mindste på det tidspunkt var de nyttige.
I 2015 kommer et nyt patch fra den samme respekterede ingeniør. Han er meget interessant. Der står følgende - vi vil randomisere hashen i tilfælde af en negativ routinghændelse. Hvad er en negativ routinghændelse? Dette er den RTO, som vi diskuterede tidligere, det vil sige, at tabet af vinduets hale er en begivenhed, der virkelig er negativ. Sandt nok er det relativt svært at gætte, at det er det.
2016, endnu et velrenommeret firma, også stort. Den skiller de sidste krykker ad og gør det sådan, at hashen, som vi tidligere lavede tilfældigt, nu ændres for hver SYN-gentransmission og efter hver RTO-timeout. Og i dette brev er det for første og sidste gang angivet det endelige mål - at sikre, at trafikken i tilfælde af tab eller kanaloverbelastning har mulighed for blødt at blive omdirigeret og bruge flere stier. Selvfølgelig, efter dette var der en masse publikationer, du kan nemt finde dem.
Selvom nej, det kan du ikke, for der har ikke været en eneste publikation om dette emne. Men vi ved det!
Og hvis du ikke helt forstår, hvad der blev gjort, vil jeg fortælle dig det nu.
Hvad blev der gjort, hvilken funktionalitet blev tilføjet til Linux-kernen? txhash ændres til en tilfældig værdi efter hver RTO-hændelse. Dette er det meget negative resultat af routing. Hashen afhænger af denne txhash, og flowetiketten afhænger af skb-hash. Der er nogle beregninger på funktioner her; alle detaljer kan ikke placeres på et dias. Hvis nogen er nysgerrige, kan du gå gennem kernekoden og tjekke.
Hvad er vigtigt her? Værdien af flowetiketfeltet ændres til et tilfældigt tal efter hver RTO. Hvordan påvirker dette vores uheldige TCP-stream?
Hvis der opstår en SACK, ændres intet, fordi vi forsøger at sende en kendt tabt pakke igen. Så langt så godt.
Men i tilfælde af RTO, forudsat at vi har tilføjet en flow-etiket til hash-funktionen på ToR, kan trafikken tage en anden rute. Og jo flere baner, jo større er chancen for, at den finder en sti, der ikke er påvirket af en fejl på en bestemt enhed.
Et problem er tilbage - RTO. Selvfølgelig er der en anden rute, men der er spildt meget tid på dette. 200 ms er meget. Et sekund er helt vildt. Tidligere talte jeg om timeouts, som tjenester er konfigureret. Så et sekund er en timeout, som normalt konfigureres af tjenesten på applikationsniveau, og i dette vil tjenesten endda være relativt rigtig. Desuden, jeg gentager, er den rigtige RTT i et moderne datacenter omkring 1 millisekund.
Hvad kan du gøre med RTO-timeouts? Timeouten, som er ansvarlig for RTO i tilfælde af tab af datapakker, kan relativt nemt konfigureres fra brugerpladsen: der er et IP-værktøj, og en af dets parametre indeholder den samme rto_min. I betragtning af at RTO selvfølgelig ikke skal justeres globalt, men for givne præfikser, ser en sådan mekanisme ganske brugbar ud.
Sandt nok, med SYN_RTO er alt noget værre. Det er naturligt naglet fast. Kernen har en fast værdi på 1 sekund, og det er det. Du kan ikke nå dertil fra brugerpladsen. Der er kun én vej.
eBPF kommer til undsætning. Det er forenklet sagt små C-programmer De kan indsættes i hooks forskellige steder i udførelsen af kernestakken og TCP-stakken, hvormed man kan ændre et meget stort antal indstillinger. Generelt er eBPF en langsigtet trend. I stedet for at skære snesevis af nye sysctl-parametre og udvide IP-værktøjet, bevæger bevægelsen sig mod eBPF og udvider dens funktionalitet. Ved hjælp af eBPF kan du dynamisk ændre overbelastningskontrol og forskellige andre TCP-indstillinger.
Men det er vigtigt for os, at det kan bruges til at ændre SYN_RTO-værdierne. Desuden er der et offentligt offentliggjort eksempel: . Hvad er der blevet gjort her? Eksemplet virker, men er i sig selv meget groft. Her antages det, at vi inde i datacentret sammenligner de første 44 bits; hvis de matcher, så er vi inde i datacentret. Og i dette tilfælde ændrer vi SYN_RTO timeout værdien til 4ms. Den samme opgave kan udføres meget mere elegant. Men dette simple eksempel viser, at dette er a) muligt; b) relativt enkel.
Hvad ved vi allerede? Det faktum, at planarkitekturen giver mulighed for skalering, viser sig at være yderst nyttigt for os, når vi aktiverer flowmærket på ToR og får mulighed for at flyde rundt i problemområder. Den bedste måde at reducere RTO- og SYN-RTO-værdier på er at bruge eBPF-programmer. Tilbage står spørgsmålet: er det sikkert at bruge et flowmærke til balancering? Og der er en nuance her.
Antag, at du har en tjeneste på dit netværk, der bor i anycast. Jeg har desværre ikke tid til at gå i detaljer om, hvad anycast er, men det er en distribueret tjeneste med forskellige fysiske servere, der er tilgængelige via den samme IP-adresse. Og her er et muligt problem: RTO-hændelsen kan ikke kun forekomme, når trafik passerer gennem stoffet. Det kan også forekomme på ToR-bufferniveauet: Når en incast-hændelse opstår, kan det endda forekomme på værten, når værten spilder noget. Når en RTO-hændelse opstår, og den ændrer flowetiketten. I dette tilfælde kan trafikken gå til en anden anycast-instans. Lad os antage, at dette er en stateful anycast, den indeholder en forbindelsestilstand - det kunne være en L3 Balancer eller en anden tjeneste. Så opstår der et problem, for efter RTO ankommer TCP-forbindelsen til serveren, som ikke ved noget om denne TCP-forbindelse. Og hvis vi ikke har tilstandsdeling mellem anycast-servere, så vil sådan trafik blive droppet, og TCP-forbindelsen vil blive brudt.
Hvad kan du gøre her? Inden for dit kontrollerede miljø, hvor du aktiverer flow-etiket-balancering, skal du registrere værdien af flow-etiketten, når du får adgang til anycast-servere. Den nemmeste måde er at gøre dette gennem det samme eBPF-program. Men her er en meget vigtig pointe - hvad skal man gøre, hvis man ikke driver et datacenternetværk, men er teleoperatør? Dette er også dit problem: begyndende med visse versioner af Juniper og Arista, inkluderer de en flow-etiket i deres hash-funktioner som standard - helt ærligt, af en grund, der er uklar for mig. Dette kan få dig til at afbryde TCP-forbindelser fra brugere, der passerer gennem dit netværk. Så jeg anbefaler stærkt, at du tjekker dine routere-indstillinger her.
På en eller anden måde forekommer det mig, at vi er klar til at gå videre til eksperimenter.
Da vi aktiverede flowmærket på ToR, forberedte eBPF-agenten, som nu lever på værterne, besluttede vi ikke at vente på den næste store fiasko, men at udføre kontrollerede eksplosioner. Vi tog ToR, som har fire uplinks, og satte drops op på en af dem. De tegnede en regel og sagde – nu mister du alle pakker. Som du kan se til venstre, har vi per-pakke overvågning, som er faldet til 75%, det vil sige, at 25% af pakkerne går tabt. Til højre er grafer over tjenester, der lever bag denne ToR. I det væsentlige er disse trafikgrafer over grænseflader med servere inde i racket. Som du kan se, sank de endnu lavere. Hvorfor faldt de lavere - ikke med 25%, men i nogle tilfælde med 3-4 gange? Hvis TCP-forbindelsen er uheldig, fortsætter den med at forsøge at nå gennem det ødelagte kryds. Dette forværres af tjenestens typiske adfærd inde i DC - for én brugeranmodning genereres N anmodninger til interne tjenester, og svaret vil gå til brugeren, enten når alle datakilder svarer, eller når der opstår timeout i applikationen niveau, som stadig mangler at blive konfigureret. Det vil sige, at alt er meget, meget dårligt.
Nu det samme eksperiment, men med flowetiketværdien aktiveret. Som du kan se, faldt vores batchovervågning til venstre med de samme 25%. Dette er helt korrekt, fordi den ikke ved noget om retransmits, den sender pakker og tæller blot forholdet mellem antallet af leverede og mistede pakker.
Og til højre er serviceplanen. Du finder ikke effekten af et problematisk led her. I de samme millisekunder strømmede trafikken fra problemområdet til de tre resterende uplinks, der ikke var berørt af problemet. Vi har et netværk, der helbreder sig selv.
Dette er mit sidste slide, tid til at opsummere. Nu håber jeg, at du ved, hvordan man bygger et selvhelbredende datacenternetværk. Du behøver ikke at gå gennem Linux-kernearkivet og lede efter specielle patches der; du ved, at Flow-etiketten i dette tilfælde løser problemet, men du skal nærme dig denne mekanisme omhyggeligt. Og jeg understreger endnu en gang, at hvis du er teleoperatør, skal du ikke bruge flow label som hash-funktion, ellers forstyrrer du dine brugeres sessioner.
Netværksingeniører skal gennemgå et konceptuelt skift: netværket begynder ikke med ToR, ikke med netværksenheden, men med værten. Et ret slående eksempel er, hvordan vi bruger eBPF både til at ændre RTO'en og til at rette flowetiketten til anycast-tjenester.
Flowmærkemekanikken er bestemt velegnet til andre applikationer inden for det kontrollerede administrative segment. Dette kan være trafik mellem datacentre, eller du kan bruge sådan mekanik på en særlig måde til at styre udgående trafik. Men jeg vil fortælle dig om dette, håber jeg, næste gang. Mange tak for din opmærksomhed.
Kilde: www.habr.com