Moderne datasentre har hundrevis av aktive enheter installert, dekket av ulike typer overvåking. Men selv en ideell ingeniør med perfekt overvåking i hånden vil være i stand til å svare riktig på en nettverksfeil på bare noen få minutter. I en rapport på Next Hop 2020-konferansen presenterte jeg en DC-nettverksdesignmetodikk, som har en unik funksjon – datasenteret helbreder seg selv på millisekunder. Mer presist fikser ingeniøren rolig problemet, mens tjenestene rett og slett ikke legger merke til det.
For mange nettverksingeniører begynner et datasenternettverk selvfølgelig med ToR, med en bryter i stativet. ToR har vanligvis to typer lenker. De små går til serverne, andre - det er N ganger flere av dem - går mot ryggradene på det første nivået, det vil si til oppkoblingene. Opplinker anses vanligvis som like, og trafikk mellom opplinker balanseres basert på en hash fra 5-tuple, som inkluderer proto, src_ip, dst_ip, src_port, dst_port. Ingen overraskelser her.
Deretter, hvordan ser planarkitekturen ut? Rygger på det første nivået er ikke koblet til hverandre, men er forbundet gjennom superspines. Bokstaven X vil være ansvarlig for superspines; det er nesten som en kryssforbindelse.
Og det er klart at på den annen side er tori koblet til alle ryggradene på første nivå. Hva er viktig i dette bildet? Hvis vi har interaksjon inne i stativet, så går samspillet selvfølgelig gjennom ToR. Hvis interaksjonen skjer inne i modulen, skjer interaksjonen gjennom ryggradene på første nivå. Hvis interaksjonen er intermodulær - som her, ToR 1 og ToR 2 - vil interaksjonen gå gjennom ryggrader på både første og andre nivå.
I teorien er en slik arkitektur lett skalerbar. Hvis vi har havnekapasitet, ledig plass i datasenteret og forhåndslagt fiber, så kan antall baner alltid økes, og dermed øke den totale kapasiteten i systemet. Dette er veldig enkelt å gjøre på papiret. Det ville vært slik i livet. Men dagens historie handler ikke om det.
Jeg vil at de riktige konklusjonene skal trekkes. Vi har mange veier inne i datasenteret. De er betinget uavhengige. Én sti inne i datasenteret er kun mulig inne i ToR. Inne i modulen har vi antall stier lik antall baner. Antall baner mellom moduler er lik produktet av antall plan og antall superspines i hvert plan. For å gjøre det klarere, for å få en følelse av skalaen, vil jeg gi tall som er gyldige for et av Yandex-datasentrene.
Det er åtte fly, hvert fly har 32 superrygger. Som et resultat viser det seg at det er åtte stier inne i modulen, og med intermodulinteraksjon er det allerede 256 av dem.
Det vil si at hvis vi utvikler Cookbook og prøver å lære å bygge feiltolerante datasentre som helbreder seg selv, så er planarkitektur det riktige valget. Det løser skaleringsproblemet, og i teorien er det enkelt. Det er mange uavhengige veier. Spørsmålet gjenstår: hvordan overlever en slik arkitektur feil? Det er ulike feil. Og vi skal diskutere dette nå.
La en av våre superrygger "bli syk". Her vendte jeg tilbake til toplansarkitekturen. Vi holder oss til disse som et eksempel fordi det blir lettere å se hva som skjer med færre bevegelige deler. La X11 bli syk. Hvordan vil dette påvirke tjenestene som lever i datasentre? Mye avhenger av hvordan feilen faktisk ser ut.
Hvis feilen er god, fanges den opp på automatiseringsnivået til samme BFD, automatiseringen legger gjerne de problematiske leddene og isolerer problemet, så er alt bra. Vi har mange stier, trafikken blir umiddelbart omdirigert til alternative ruter, og tjenester vil ikke merke noe. Dette er et godt manus.
Et dårlig scenario er hvis vi har konstante tap, og automatikken ikke merker problemet. For å forstå hvordan dette påvirker en applikasjon, må vi bruke litt tid på å diskutere hvordan TCP fungerer.
Jeg håper jeg ikke sjokkerer noen med denne informasjonen: TCP er en overføringsbekreftelsesprotokoll. Det vil si at i det enkleste tilfellet sender avsenderen to pakker og mottar en kumulativ kvittering på dem: "Jeg mottok to pakker."
Etter det vil han sende to pakker til, og situasjonen vil gjenta seg. Jeg beklager på forhånd for litt forenkling. Dette scenariet er riktig hvis vinduet (antall pakker under flyturen) er to. Selvfølgelig, i det generelle tilfellet er dette ikke nødvendigvis tilfelle. Men vindusstørrelsen påvirker ikke pakkevideresendingskonteksten.
Hva skjer hvis vi mister pakke 3? I dette tilfellet vil mottakeren motta pakkene 1, 2 og 4. Og han vil eksplisitt fortelle avsenderen ved å bruke SACK-alternativet: "Du vet, tre ankom, men midten gikk tapt." Han sier: "Ack 2, SACK 4."
I dette øyeblikket gjentar avsenderen uten problemer nøyaktig pakken som gikk tapt.
Men hvis den siste pakken i vinduet går tapt, vil situasjonen se helt annerledes ut.
Mottakeren mottar de tre første pakkene og begynner først og fremst å vente. Takket være noen optimaliseringer i Linux-kjernens TCP-stack, vil den vente på en paret pakke med mindre flaggene eksplisitt indikerer at det er den siste pakken eller noe lignende. Den vil vente til tidsavbruddet for forsinket ACK utløper og deretter sende en bekreftelse på de tre første pakkene. Men nå vil avsenderen vente. Han vet ikke om den fjerde pakken har gått tapt eller er i ferd med å ankomme. Og for ikke å overbelaste nettverket, vil det prøve å vente på en eksplisitt indikasjon på at pakken er tapt, eller på at RTO-tidsavbruddet utløper.
Hva er RTO-tidsavbrudd? Dette er maksimum av RTT beregnet av TCP-stakken og en viss konstant. Hva slags konstant dette er, skal vi nå diskutere.
Men det viktige er at hvis vi er uheldige igjen og den fjerde pakken går tapt igjen, så dobles RTO. Det vil si at hvert mislykket forsøk betyr å doble tidsavbruddet.
La oss nå se hva denne basen er lik. Som standard er minimum RTO 200 ms. Dette er minimum RTO for datapakker. For SYN-pakker er det annerledes, 1 sekund. Som du kan se, vil selv det første forsøket på å sende pakker på nytt ta 100 ganger lengre tid enn RTT inne i datasenteret.
La oss nå gå tilbake til scenariet vårt. Hva skjer med tjenesten? Tjenesten begynner å miste pakker. La tjenesten først være betinget heldig og miste noe midt i vinduet, så mottar den en SACK og sender på nytt pakkene som gikk tapt.
Men hvis uflaksen gjentar seg, så har vi en RTO. Hva er viktig her? Ja, vi har mange veier i nettverket vårt. Men TCP-trafikken til en bestemt TCP-forbindelse vil fortsette å gå gjennom den samme ødelagte stabelen. Pakketap, forutsatt at denne magiske X11-en vår ikke går ut av seg selv, fører ikke til at trafikken flyter inn i områder som ikke er problematiske. Vi prøver å levere pakken gjennom den samme ødelagte stabelen. Dette fører til en gjennomgripende feil: et datasenter er et sett med applikasjoner som samhandler, og noen av TCP-tilkoblingene til alle disse applikasjonene begynner å bli dårligere - fordi superspine påvirker alle applikasjoner som finnes inne i datasenteret. Som ordtaket sier: hvis du ikke sko en hest, ble hesten halt; hesten ble halt - rapporten ble ikke levert; rapporten ble ikke levert - vi tapte krigen. Bare her er tellingen i sekunder fra det øyeblikket problemet oppstår til det stadiet av degradering tjenestene begynner å føle. Dette betyr at brukere kan gå glipp av noe et sted.
Det er to klassiske løsninger som utfyller hverandre. Den første er tjenester som prøver å sette sugerør i og løse problemet slik: «La oss justere noe i TCP-stakken. La oss ta timeouts på applikasjonsnivå eller langvarige TCP-økter med interne helsesjekker.» Problemet er at slike løsninger: a) ikke skaleres i det hele tatt; b) er svært dårlig sjekket. Det vil si, selv om tjenesten ved et uhell konfigurerer TCP-stakken på en måte som gjør den bedre, for det første er det usannsynlig at den vil være aktuelt for alle applikasjoner og alle datasentre, og for det andre, mest sannsynlig, vil den ikke forstå at det ble gjort riktig, og hva ikke. Det vil si at det fungerer, men det fungerer dårlig og skalerer ikke. Og hvis det er et nettverksproblem, hvem har skylden? Selvfølgelig, NOC. Hva gjør NOC?
Mange tjenester mener at i NOC-arbeid skjer noe slikt. Men for å være ærlig, ikke bare det.
NOC i den klassiske ordningen er engasjert i utviklingen av mange overvåkingssystemer. Disse er både svart boks og hvit boks overvåking. Om et eksempel på svart boks-ryggradsovervåking Alexander Klimenko ved siste neste hopp. Denne overvåkingen fungerer forresten. Men selv ideell overvåking vil ha en tidsforsinkelse. Vanligvis er dette noen få minutter. Etter at den går av, trenger ingeniørene på vakt tid til å dobbeltsjekke funksjonen, lokalisere problemet og deretter slukke problemområdet. Det vil si at i beste fall tar behandling av problemet 5 minutter, i verste fall 20 minutter, hvis det ikke umiddelbart er åpenbart hvor tapene oppstår. Det er klart at hele denne tiden - 5 eller 20 minutter - vil tjenestene våre fortsette å lide, noe som sannsynligvis ikke er bra.
Hva ønsker du egentlig å motta? Vi har så mange måter. Og problemer oppstår nettopp fordi TCP-strømmer som er uheldige fortsetter å bruke samme rute. Vi trenger noe som lar oss bruke flere ruter innenfor en enkelt TCP-tilkobling. Det ser ut til at vi har en løsning. Det er TCP, som kalles multipath TCP, det vil si TCP for flere baner. Riktignok ble den utviklet for en helt annen oppgave - for smarttelefoner som har flere nettverksenheter. For å maksimere overføring eller lage primær-/sikkerhetskopieringsmodus ble det utviklet en mekanisme som skaper flere tråder (økter) transparent for applikasjonen og lar deg bytte mellom dem i tilfelle feil. Eller, som sagt, maksimere streken.
Men det er en nyanse her. For å forstå hva det er, må vi se på hvordan tråder etableres.
Tråder installeres sekvensielt. Den første tråden installeres først. Etterfølgende tråder settes deretter ved hjelp av informasjonskapselen som allerede er avtalt i den tråden. Og her er problemet.
Problemet er at hvis den første tråden ikke etablerer seg, vil den andre og tredje tråden aldri oppstå. Det vil si at flerveis TCP ikke løser tapet av en SYN-pakke i den første flyten. Og hvis SYN går tapt, blir flerveis TCP til vanlig TCP. Dette betyr at i et datasentermiljø vil det ikke hjelpe oss med å løse problemet med tap på fabrikken og lære å bruke flere baner i tilfelle feil.
Hva kan hjelpe oss? Noen av dere har allerede gjettet ut fra tittelen at et viktig felt i vår videre historie vil være IPv6-flytetikettens overskriftsfelt. Dette er faktisk et felt som vises i v6, det er ikke i v4, det opptar 20 biter, og det har vært uenighet om bruken i lang tid. Dette er veldig interessant - det var tvister, noe ble fikset i RFC, og samtidig dukket det opp en implementering i Linux-kjernen, som ikke ble dokumentert noe sted.
Jeg inviterer deg til å bli med meg på en liten undersøkelse. La oss ta en titt på hva som har skjedd i Linux-kjernen de siste årene.
år 2014. En ingeniør fra et stort og respektert selskap legger til funksjonaliteten til Linux-kjernen avhengigheten av flytetikettverdien på socket-hashen. Hva prøvde de å fikse her? Dette er relatert til RFC 6438, som diskuterte følgende problem. Inne i datasenteret er IPv4 ofte innkapslet i IPv6-pakker, fordi selve fabrikken er IPv6, men IPv4 må på en eller annen måte gis utenfor. Lenge var det problemer med brytere som ikke kunne se under to IP-hoder for å komme til TCP eller UDP og finne src_ports, dst_ports der. Det viste seg at hashen, hvis du ser på de to første IP-hodene, viste seg å være nesten fikset. For å unngå dette, slik at balansering av denne innkapslede trafikken fungerer riktig, ble det foreslått å legge til hashen til den 5-tuppel innkapslede pakken til verdien av flytetikettfeltet. Omtrent det samme ble gjort for andre innkapslingsordninger, for UDP, for GRE, sistnevnte brukte GRE Key-feltet. På en eller annen måte er målene her klare. Og i det minste på det tidspunktet var de nyttige.
I 2015 kommer en ny oppdatering fra den samme respekterte ingeniøren. Han er veldig interessant. Det står følgende - vi vil randomisere hashen i tilfelle en negativ rutinghendelse. Hva er en negativ rutinghendelse? Dette er RTO som vi diskuterte tidligere, det vil si at tapet av vinduets hale er en hendelse som virkelig er negativ. Riktignok er det relativt vanskelig å gjette at dette er det.
2016, et annet anerkjent selskap, også stort. Den demonterer de siste krykkene og gjør det slik at hashen, som vi tidligere gjorde tilfeldig, nå endres for hver SYN-reoverføring og etter hver RTO-timeout. Og i dette brevet, for første og siste gang, er det endelige målet angitt – å sikre at trafikk ved tap eller kanaloverbelastning har muligheten til å bli mykt omdirigert og bruke flere veier. Selvfølgelig, etter dette var det mange publikasjoner, du kan enkelt finne dem.
Selv om nei, du kan ikke, fordi det ikke har vært en eneste publikasjon om dette emnet. Men vi vet!
Og hvis du ikke helt forstår hva som ble gjort, skal jeg fortelle deg det nå.
Hva ble gjort, hvilken funksjonalitet ble lagt til Linux-kjernen? txhash endres til en tilfeldig verdi etter hver RTO-hendelse. Dette er det svært negative resultatet av ruting. Hashen avhenger av denne txhash, og flytetiketten avhenger av skb-hash. Det er noen beregninger på funksjoner her; alle detaljene kan ikke plasseres på ett lysbilde. Hvis noen er nysgjerrige, kan du gå gjennom kjernekoden og sjekke.
Hva er viktig her? Verdien av flytetikettfeltet endres til et tilfeldig tall etter hver RTO. Hvordan påvirker dette vår uheldige TCP-strøm?
Hvis en SACK oppstår, endres ingenting fordi vi prøver å sende en kjent tapt pakke på nytt. Så langt så bra.
Men når det gjelder RTO, forutsatt at vi har lagt til en flytetikett til hash-funksjonen på ToR, kan trafikken ta en annen rute. Og jo flere baner, jo større er sjansen for at den finner en sti som ikke er påvirket av en feil på en bestemt enhet.
Ett problem gjenstår - RTO. Det finnes selvsagt en annen rute, men det går mye tid bort på dette. 200 ms er mye. Et sekund er helt vilt. Tidligere snakket jeg om tidsavbrudd som tjenester er konfigurert. Så et sekund er en timeout, som vanligvis konfigureres av tjenesten på applikasjonsnivå, og i dette vil tjenesten til og med være relativt riktig. Dessuten, jeg gjentar, er den virkelige RTT inne i et moderne datasenter rundt 1 millisekund.
Hva kan du gjøre med RTO-tidsavbrudd? Tidsavbruddet, som er ansvarlig for RTO i tilfelle tap av datapakker, kan konfigureres relativt enkelt fra brukerplass: det er et IP-verktøy, og en av parameterne inneholder den samme rto_min. Tatt i betraktning at RTO, selvfølgelig, ikke må justeres globalt, men for gitte prefikser, ser en slik mekanisme ganske brukbar ut.
Riktignok er alt noe verre med SYN_RTO. Det er naturlig spikret. Kjernen har en fast verdi på 1 sekund, og det er det. Du kan ikke nå dit fra brukerplassen. Det er bare én vei.
eBPF kommer til unnsetning. For å si det enkelt er dette små C-programmer.De kan settes inn i hooks forskjellige steder i utførelsen av kjernestakken og TCP-stakken, som du kan endre et veldig stort antall innstillinger med. Generelt er eBPF en langsiktig trend. I stedet for å kutte dusinvis av nye sysctl-parametere og utvide IP-verktøyet, beveger bevegelsen seg mot eBPF og utvider funksjonaliteten. Ved å bruke eBPF kan du dynamisk endre overbelastningskontroller og forskjellige andre TCP-innstillinger.
Men det er viktig for oss at det kan brukes til å endre SYN_RTO-verdiene. Dessuten er det et offentlig publisert eksempel: . Hva er gjort her? Eksemplet fungerer, men er i seg selv veldig røft. Her antas det at inne i datasenteret sammenligner vi de første 44 bitene; hvis de samsvarer, så er vi inne i datasenteret. Og i dette tilfellet endrer vi SYN_RTO timeout-verdien til 4ms. Den samme oppgaven kan gjøres mye mer elegant. Men dette enkle eksempelet viser at dette er a) mulig; b) relativt enkelt.
Hva vet vi allerede? At flyarkitekturen gir rom for skalering, viser seg å være ekstremt nyttig for oss når vi aktiverer flytetiketten på ToR og får muligheten til å flyte rundt problemområder. Den beste måten å redusere RTO- og SYN-RTO-verdier på er å bruke eBPF-programmer. Spørsmålet gjenstår: er det trygt å bruke en flytetikett for balansering? Og det er en nyanse her.
Anta at du har en tjeneste på nettverket ditt som bor i anycast. Jeg har dessverre ikke tid til å gå i detalj om hva anycast er, men det er en distribuert tjeneste med forskjellige fysiske servere tilgjengelig via samme IP-adresse. Og her er et mulig problem: RTO-hendelsen kan ikke bare oppstå når trafikk passerer gjennom stoffet. Det kan også forekomme på ToR-buffernivå: når en incast-hendelse inntreffer, kan det til og med oppstå på verten når verten søler noe. Når en RTO-hendelse oppstår og den endrer flytetiketten. I dette tilfellet kan trafikken gå til en annen anycast-forekomst. La oss anta at dette er en stateful anycast, den inneholder en tilkoblingstilstand - det kan være en L3 Balancer eller en annen tjeneste. Da oppstår et problem, for etter RTO kommer TCP-forbindelsen til serveren, som ikke vet noe om denne TCP-forbindelsen. Og hvis vi ikke har tilstandsdeling mellom anycast-servere, vil slik trafikk bli droppet og TCP-forbindelsen vil bli brutt.
Hva kan du gjøre her? Innenfor ditt kontrollerte miljø, der du aktiverer flytetikettbalansering, må du registrere verdien av flytetiketten når du får tilgang til anycast-servere. Den enkleste måten er å gjøre dette gjennom det samme eBPF-programmet. Men her er et veldig viktig poeng - hva skal du gjøre hvis du ikke driver et datasenternettverk, men er en teleoperatør? Dette er problemet ditt også: Fra og med visse versjoner av Juniper og Arista inkluderer de en flytetikett i hash-funksjonene sine som standard - ærlig talt, av en grunn som er uklar for meg. Dette kan føre til at du mister TCP-tilkoblinger fra brukere som går gjennom nettverket ditt. Så jeg anbefaler på det sterkeste å sjekke ruterinnstillingene dine her.
På en eller annen måte virker det for meg at vi er klare til å gå videre til eksperimenter.
Da vi aktiverte flytetiketten på ToR, forberedte eBPF-agenten, som nå lever på vertene, bestemte vi oss for å ikke vente på den neste store feilen, men å gjennomføre kontrollerte eksplosjoner. Vi tok ToR, som har fire opplinker, og satte opp drops på en av dem. De tegnet en regel og sa - nå mister du alle pakker. Som du kan se til venstre har vi overvåking per pakke, som har sunket til 75 %, det vil si at 25 % av pakkene går tapt. Til høyre er grafer over tjenester som lever bak denne ToR. I hovedsak er dette trafikkgrafer over grensesnittene med servere inne i racket. Som du ser sank de enda lavere. Hvorfor falt de lavere - ikke med 25%, men i noen tilfeller med 3-4 ganger? Hvis TCP-tilkoblingen er uheldig, fortsetter den å prøve å nå gjennom det ødelagte krysset. Dette forverres av den typiske oppførselen til tjenesten inne i DC - for én brukerforespørsel genereres N forespørsler til interne tjenester, og svaret vil gå til brukeren enten når alle datakilder svarer, eller når det oppstår et tidsavbrudd i applikasjonen nivå, som fortsatt må konfigureres. Det vil si at alt er veldig, veldig dårlig.
Nå det samme eksperimentet, men med flytetikettverdien aktivert. Som du kan se, til venstre falt batchovervåkingen vår med de samme 25 %. Dette er helt riktig, fordi den ikke kan noe om retransmits, den sender pakker og teller rett og slett forholdet mellom antall leverte og tapte pakker.
Og til høyre er serviceplanen. Du finner ikke effekten av et problematisk ledd her. I løpet av de samme millisekunder strømmet trafikk fra problemområdet til de tre gjenværende opplinkene som ikke ble berørt av problemet. Vi har et nettverk som helbreder seg selv.
Dette er mitt siste lysbilde, tid for å oppsummere. Nå håper jeg du vet hvordan du bygger et selvhelbredende datasenternettverk. Du trenger ikke å gå gjennom Linux-kjernearkivet og se etter spesielle patcher der; du vet at Flow-etiketten i dette tilfellet løser problemet, men du må nærme deg denne mekanismen nøye. Og jeg understreker nok en gang at hvis du er teleoperatør, bør du ikke bruke flytetikett som hash-funksjon, ellers vil du forstyrre brukernes økter.
Nettverksingeniører må gjennomgå et konseptuelt skifte: nettverket begynner ikke med ToR, ikke med nettverksenheten, men med verten. Et ganske slående eksempel er hvordan vi bruker eBPF både til å endre RTO og for å fikse flytetiketten mot anycast-tjenester.
Flytetikettmekanikken er absolutt egnet for andre applikasjoner innen det kontrollerte administrative segmentet. Dette kan være trafikk mellom datasentre, eller du kan bruke slik mekanikk på en spesiell måte for å administrere utgående trafikk. Men jeg skal fortelle deg om dette, håper jeg neste gang. Tusen takk for oppmerksomheten.
Kilde: www.habr.com