Moderni data centri imaju stotine instaliranih aktivnih uređaja, pokrivenih različitim vrstama nadzora. Ali čak i idealan inženjer sa savršenim nadzorom u ruci moći će ispravno odgovoriti na kvar mreže za samo nekoliko minuta. U izvještaju na Next Hop 2020 konferenciji, predstavio sam metodologiju dizajna DC mreže, koja ima jedinstvenu karakteristiku - podatkovni centar se liječi u milisekundama. Tačnije, inženjer mirno rješava problem, dok ga servisi jednostavno ne primjećuju.
Za mnoge mrežne inženjere, mreža podatkovnih centara počinje, naravno, sa ToR-om, sa prekidačem u stalku. ToR obično ima dvije vrste veza. Mali idu na servere, drugi - ima ih N puta više - idu prema bodljama prvog nivoa, odnosno ka njegovim uplinkovima. Uplinkovi se obično smatraju jednakim, a promet između uplinkova je uravnotežen na osnovu heša od 5-torke, što uključuje proto, src_ip, dst_ip, src_port, dst_port. Nema iznenađenja.
Zatim, kako izgleda arhitektura plana? Kičme prvog nivoa nisu međusobno povezane, već su povezane preko superspina. Slovo X će biti odgovorno za superspine; gotovo je kao unakrsna veza.
I jasno je da su, s druge strane, tori povezani sa svim bodljama prvog nivoa. Šta je važno na ovoj slici? Ako imamo interakciju unutar stalka, onda interakcija, naravno, ide kroz ToR. Ako se interakcija dogodi unutar modula, tada se interakcija događa kroz bodlje prvog nivoa. Ako je interakcija intermodularna - kao ovdje, ToR 1 i ToR 2 - tada će interakcija ići kroz kičme i prvog i drugog nivoa.
U teoriji, takva arhitektura je lako skalabilna. Ako imamo kapacitet porta, rezervni prostor u data centru i prethodno postavljeno vlakno, tada se broj traka uvijek može povećati, čime se povećava ukupni kapacitet sistema. Ovo je vrlo lako uraditi na papiru. Tako bi bilo u životu. Ali današnja priča nije o tome.
Želim da se donesu pravi zaključci. Imamo mnogo puteva unutar data centra. Oni su uslovno nezavisni. Jedna putanja unutar data centra je moguća samo unutar ToR-a. Unutar modula imamo broj staza jednak broju traka. Broj putanja između modula jednak je proizvodu broja ravnina i broja superspina u svakoj ravni. Da bi bilo jasnije, da biste stekli uvid u razmeru, navest ću brojeve koji važe za jedan od Yandex data centara.
Ima osam aviona, svaki avion ima 32 superspina. Kao rezultat toga, ispada da postoji osam putanja unutar modula, a sa intermodulnom interakcijom već ih ima 256.
Odnosno, ako razvijamo Cookbook, pokušavajući da naučimo kako da izgradimo centre podataka otpornih na greške koji sami sebe leče, onda je planarna arhitektura pravi izbor. To rješava problem skaliranja, a u teoriji je to lako. Postoji mnogo nezavisnih puteva. Ostaje pitanje: kako takva arhitektura preživljava neuspjehe? Ima raznih kvarova. I o tome ćemo sada razgovarati.
Neka nam se "razboli" jedna od naših superkičmi. Ovdje sam se vratio dvostranoj arhitekturi. Zadržat ćemo se ovih kao primjera jer će jednostavno biti lakše vidjeti što se događa s manje pokretnih dijelova. Neka se X11 razboli. Kako će to uticati na usluge koje žive unutar data centara? Mnogo toga zavisi od toga kako neuspeh zapravo izgleda.
Ako je kvar dobar, uhvati se na nivou automatizacije istog BFD-a, automatika sretno postavlja problematične spojeve i izoluje problem, onda je sve u redu. Imamo mnogo puteva, saobraćaj se trenutno preusmjerava na alternativne rute, a službe neće ništa primijetiti. Ovo je dobar scenario.
Loš scenario je ako imamo stalne gubitke, a automatika ne uoči problem. Da bismo razumjeli kako ovo utječe na aplikaciju, morat ćemo provesti malo vremena raspravljajući o tome kako TCP funkcionira.
Nadam se da nikoga neću šokirati ovom informacijom: TCP je protokol za potvrdu prijenosa. Odnosno, u najjednostavnijem slučaju, pošiljalac šalje dva paketa i dobija kumulativni ack na njih: „Primio sam dva paketa“.
Nakon toga će poslati još dva paketa i situacija će se ponoviti. Unaprijed se izvinjavam na malom pojednostavljenju. Ovaj scenario je ispravan ako je prozor (broj paketa u letu) dva. Naravno, u opštem slučaju to nije nužno slučaj. Ali veličina prozora ne utiče na kontekst prosljeđivanja paketa.
Šta se dešava ako izgubimo paket 3? U ovom slučaju, primalac će primiti pakete 1, 2 i 4. I on će pošiljaocu eksplicitno reći koristeći SACK opciju: „Znate, stigla su tri, ali je sredina izgubljena.“ On kaže, "Ack 2, SACK 4."
U ovom trenutku pošiljalac bez problema ponavlja upravo izgubljeni paket.
Ali ako se izgubi posljednji paket u prozoru, situacija će izgledati potpuno drugačije.
Primalac prima prva tri paketa i pre svega počinje da čeka. Zahvaljujući nekim optimizacijama u TCP steku Linux kernela, on će čekati na upareni paket osim ako zastavice eksplicitno ne ukazuju da je to posljednji paket ili nešto slično. Sačekaće dok vremensko ograničenje odloženog ACK-a ne istekne, a zatim će poslati potvrdu za prva tri paketa. Ali sada će pošiljalac čekati. Ne zna da li je četvrti paket izgubljen ili će uskoro stići. A kako ne bi preopteretio mrežu, pokušat će sačekati eksplicitnu indikaciju da je paket izgubljen, ili da istekne RTO timeout.
Šta je RTO timeout? Ovo je maksimum RTT izračunat od strane TCP steka i neke konstante. Kakva je to konstanta, sada ćemo razgovarati.
Ali važno je da ako opet nemamo sreće i ponovo izgubimo četvrti paket, onda se RTO udvostručuje. Odnosno, svaki neuspješan pokušaj znači udvostručavanje vremena čekanja.
Sada da vidimo čemu je ova baza jednaka. Podrazumevano, minimalni RTO je 200 ms. Ovo je minimalni RTO za pakete podataka. Za SYN pakete je drugačije, 1 sekunda. Kao što vidite, čak i prvi pokušaj ponovnog slanja paketa će trajati 100 puta duže od RTT-a unutar centra podataka.
Vratimo se sada na naš scenario. Šta se dešava sa servisom? Usluga počinje da gubi pakete. Neka usluga u početku bude uslovno srećna i izgubi nešto na sredini prozora, zatim dobije SACK i ponovo pošalje izgubljene pakete.
Ali ako se loša sreća ponovi, onda imamo RTO. Šta je tu važno? Da, imamo puno puteva u našoj mreži. Ali TCP saobraćaj jedne određene TCP veze će nastaviti da prolazi kroz isti prekinuti stek. Gubici paketa, pod uslovom da se ovaj naš magični X11 ne ugasi sam, ne dovode do odlivanja saobraćaja u područja koja nisu problematična. Pokušavamo isporučiti paket kroz isti slomljeni stek. To dovodi do kaskadnog neuspjeha: podatkovni centar je skup aplikacija koje djeluju u interakciji, a neke od TCP veza svih ovih aplikacija počinju degradirati - jer superspine utječe na sve aplikacije koje postoje unutar podatkovnog centra. Kako se kaže: ako konja nisi potkovao, konj je hrom; konj je hrom - izvještaj nije dostavljen; izvještaj nije dostavljen - izgubili smo rat. Samo ovdje se računa u sekundama od trenutka kada se problem pojavi do faze degradacije koju servisi počinju osjećati. To znači da korisnici možda negdje nešto propuštaju.
Postoje dva klasična rješenja koja se međusobno nadopunjuju. Prvi su servisi koji pokušavaju staviti slamke i riješiti problem ovako: „Hajde da podesimo nešto u TCP steku. Hajde da napravimo tajmaute na nivou aplikacije ili dugotrajne TCP sesije sa internim zdravstvenim provjerama.” Problem je u tome što takva rješenja: a) uopće nemaju veličinu; b) su vrlo slabo provjereni. To jest, čak i ako usluga slučajno konfiguriše TCP stog na način koji ga čini boljim, prvo, malo je vjerovatno da će biti primjenjiv na sve aplikacije i sve podatkovne centre, a drugo, najvjerovatnije, neće shvatiti da je to učinjeno ispravno, a šta ne. Odnosno, radi, ali loše radi i ne raste. A ako postoji problem sa mrežom, ko je kriv? Naravno, NOC. Šta radi NOC?
Mnoge službe smatraju da se u radu NOO-a dešava ovako nešto. Ali da budem iskren, ne samo to.
NOC se u klasičnoj šemi bavi razvojem mnogih sistema za praćenje. To su i nadzor crne kutije i bijele kutije. O primjeru praćenja kičme u crnoj kutiji Aleksandar Klimenko na posljednjem Next Hop-u. Inače, ovaj monitoring radi. Ali čak i idealno praćenje će imati vremensko kašnjenje. Obično je to nekoliko minuta. Nakon što se ugasi, dežurnim inženjerima treba vremena da još jednom provjere njegov rad, lokaliziraju problem i zatim ugase problematično područje. Odnosno, u najboljem slučaju, lečenje problema traje 5 minuta, u najgorem slučaju 20 minuta, ako nije odmah vidljivo gde nastaju gubici. Jasno je da će sve ovo vrijeme - 5 ili 20 minuta - naše usluge i dalje trpeti, što vjerovatno nije dobro.
Šta biste zaista željeli dobiti? Imamo toliko načina. A problemi nastaju upravo zato što TCP tokovi koji nemaju sreće nastavljaju koristiti istu rutu. Trebamo nešto što će nam omogućiti korištenje više ruta unutar jedne TCP veze. Čini se da imamo rješenje. Postoji TCP, koji se naziva multipath TCP, odnosno TCP za više putanja. Istina, razvijen je za potpuno drugačiji zadatak - za pametne telefone koji imaju nekoliko mrežnih uređaja. Da bi se maksimizirao prijenos ili napravio primarni/rezervni način rada, razvijen je mehanizam koji kreira više niti (sesija) transparentno za aplikaciju i omogućava vam da prelazite između njih u slučaju kvara. Ili, kao što sam rekao, maksimizirajte niz.
Ali ovdje postoji nijansa. Da bismo razumeli šta je to, moraćemo da pogledamo kako se uspostavljaju niti.
Niti se instaliraju uzastopno. Prva nit se instalira prva. Naredne niti se zatim postavljaju pomoću kolačića koji je već dogovoren unutar te niti. I ovdje je problem.
Problem je u tome što ako se prva nit ne uspostavi, druga i treća nit nikada neće nastati. To jest, multipath TCP ne rješava gubitak SYN paketa u prvom toku. A ako se SYN izgubi, multipath TCP se pretvara u običan TCP. To znači da nam u okruženju data centra neće pomoći da rešimo problem gubitaka u fabrici i naučimo da koristimo više putanja u slučaju kvara.
Šta nam može pomoći? Neki od vas su već iz naslova pogodili da će važno polje u našoj daljoj priči biti polje zaglavlja IPv6 oznake protoka. Zaista, ovo je polje koje se pojavljuje u v6, nije ga u v4, zauzima 20 bita, a već duže vrijeme postoje kontroverze oko njegove upotrebe. Ovo je vrlo zanimljivo - bilo je sporova, nešto je popravljeno unutar RFC-a, a istovremeno se pojavila implementacija u Linux kernelu, koja nije nigdje dokumentirana.
Pozivam vas da pođete sa mnom na malu istragu. Hajde da pogledamo šta se dešavalo u Linux kernelu u proteklih nekoliko godina.
godina 2014. Inženjer iz jedne velike i cijenjene kompanije dodaje funkcionalnosti Linux kernela ovisnost vrijednosti oznake toka od heša utičnice. Šta su pokušavali da poprave ovde? Ovo se odnosi na RFC 6438, koji je raspravljao o sljedećem pitanju. Unutar podatkovnog centra, IPv4 je često inkapsuliran u IPv6 pakete, jer je sama fabrika IPv6, ali IPv4 se nekako mora dati van. Dugo su postojali problemi sa prekidačima koji nisu mogli pogledati ispod dva IP zaglavlja da bi došli do TCP ili UDP i tamo pronašli src_ports, dst_ports. Ispostavilo se da je heš, ako pogledate prva dva IP zaglavlja, bio skoro fiksiran. Da bi se to izbjeglo, kako bi balansiranje ovog inkapsuliranog prometa funkcioniralo ispravno, predloženo je da se doda heš inkapsuliranog paketa od 5 tuple u vrijednost polja oznake toka. Približno ista stvar je urađena za druge šeme enkapsulacije, za UDP, za GRE, potonji je koristio polje GRE Key. Na ovaj ili onaj način, ciljevi su ovdje jasni. I barem su u tom trenutku bili korisni.
U 2015, nova zakrpa dolazi od istog uglednog inženjera. On je veoma interesantan. Piše sljedeće - randomizirat ćemo heš u slučaju negativnog rutiranja. Šta je negativni događaj usmjeravanja? Ovo je RTO o kojem smo ranije govorili, odnosno gubitak repa prozora je događaj koji je zaista negativan. Istina, relativno je teško pretpostaviti da je to to.
2016, još jedna renomirana kompanija, takođe velika. On rastavlja posljednje štake i čini tako da se hash, koji smo prethodno napravili nasumično, sada mijenja za svaki SYN retransmisiju i nakon svakog RTO timeouta. I u ovom pismu, po prvi i posljednji put, navodi se krajnji cilj - osigurati da saobraćaj u slučaju gubitaka ili zagušenja kanala ima mogućnost mekog preusmjeravanja i korištenja više puta. Naravno, nakon ovoga je bilo puno publikacija, lako ih možete pronaći.
Iako ne, ne možete, jer nije bilo nijedne publikacije na ovu temu. Ali znamo!
A ako ne razumete u potpunosti šta je urađeno, sada ću vam reći.
Šta je urađeno, koja je funkcionalnost dodata Linux kernelu? txhash se mijenja u slučajnu vrijednost nakon svakog RTO događaja. Ovo je vrlo negativan rezultat rutiranja. Heš zavisi od ovog txhash-a, a oznaka toka zavisi od skb heša. Ovdje postoje neke kalkulacije funkcija; svi detalji se ne mogu staviti na jedan slajd. Ako je neko radoznao, može proći kroz kod kernela i provjeriti.
Šta je tu važno? Vrijednost polja oznake toka mijenja se u nasumični broj nakon svakog RTO-a. Kako to utječe na naš nesretni TCP stream?
Ako se dogodi SACK, ništa se ne mijenja jer pokušavamo ponovo poslati poznati izgubljeni paket. Zasada je dobro.
Ali u slučaju RTO-a, pod uslovom da smo dodali oznaku toka heš funkciji na ToR-u, saobraćaj može ići drugom rutom. I što je više traka, veća je šansa da će pronaći putanju na koju ne utječe kvar na određenom uređaju.
Jedan problem ostaje - RTO. Naravno, postoji i druga ruta, ali na ovo se gubi mnogo vremena. 200 ms je puno. Sekunda je potpuno divlja. Ranije sam govorio o vremenskim ograničenjima za koje su usluge konfigurisane. Dakle, sekunda je vremensko ograničenje, koje obično konfiguriše servis na nivou aplikacije, a u ovom slučaju servis će čak biti relativno ispravan. Štaviše, ponavljam, pravi RTT unutar modernog data centra je oko 1 milisekunde.
Šta možete učiniti s RTO timeoutima? Timeout, koji je odgovoran za RTO u slučaju gubitka paketa podataka, može se relativno lako konfigurirati iz korisničkog prostora: postoji IP pomoćni program, a jedan od njegovih parametara sadrži isti rto_min. S obzirom da RTO, naravno, treba prilagoditi ne globalno, već za date prefikse, takav mehanizam izgleda prilično izvodljiv.
Istina, sa SYN_RTO je sve nešto gore. Prirodno je prikovan. Kernel ima fiksnu vrijednost od 1 sekunde, i to je to. Ne možete doći tamo iz korisničkog prostora. Postoji samo jedan način.
eBPF dolazi u pomoć. Pojednostavljeno rečeno, radi se o malim C programima. Mogu se ubaciti u kuke na različita mjesta u izvršavanju steka kernela i TCP steka, pomoću kojih možete promijeniti vrlo veliki broj postavki. Općenito, eBPF je dugoročni trend. Umjesto smanjenja desetina novih sysctl parametara i proširenja IP uslužnog programa, kretanje se kreće ka eBPF-u i proširuje njegovu funkcionalnost. Koristeći eBPF, možete dinamički mijenjati kontrole zagušenja i razne druge TCP postavke.
Ali za nas je važno da se može koristiti za promjenu SYN_RTO vrijednosti. Štaviše, postoji javno objavljen primjer: . Šta je ovde urađeno? Primjer radi, ali je sam po sebi vrlo grub. Ovdje se pretpostavlja da unutar podatkovnog centra upoređujemo prva 44 bita; ako se poklapaju, onda smo unutar podatkovnog centra. I u ovom slučaju mijenjamo vrijednost vremenskog ograničenja SYN_RTO na 4ms. Isti zadatak se može obaviti mnogo elegantnije. Ali ovaj jednostavan primjer pokazuje da je to a) moguće; b) relativno jednostavno.
Šta već znamo? Činjenica da ravan arhitektura dozvoljava skaliranje, ispostavilo se da je izuzetno korisna za nas kada omogućimo oznaku toka na ToR-u i dobijemo mogućnost protoka oko problematičnih područja. Najbolji način za smanjenje vrijednosti RTO i SYN-RTO je korištenje eBPF programa. Ostaje pitanje: da li je bezbedno koristiti oznaku protoka za balansiranje? I tu postoji nijansa.
Pretpostavimo da imate uslugu na vašoj mreži koja živi u anycast. Nažalost, nemam vremena da ulazim u detalje o tome šta je anycast, ali to je distribuirana usluga sa različitim fizičkim serverima dostupnim preko iste IP adrese. I evo mogućeg problema: RTO događaj se može dogoditi ne samo kada promet prolazi kroz tkivo. Može se desiti i na nivou bafera ToR: kada se dogodi incast događaj, može se čak dogoditi i na hostu kada host nešto prolije. Kada se dogodi RTO događaj i promijeni oznaku toka. U ovom slučaju, promet može ići na drugu anycast instancu. Pretpostavimo da je ovo bilo kakvo prebacivanje stanja koje sadrži stanje veze - može biti L3 Balancer ili neka druga usluga. Tada nastaje problem, jer nakon RTO TCP konekcija stiže na server koji ne zna ništa o ovoj TCP vezi. A ako nemamo dijeljenje stanja između anycast servera, tada će takav promet biti odbačen i TCP veza će biti prekinuta.
sta mozes da radis ovde? Unutar vašeg kontroliranog okruženja, gdje omogućavate balansiranje oznaka toka, trebate zabilježiti vrijednost oznake toka kada pristupate anycast serverima. Najlakši način je da to učinite kroz isti eBPF program. Ali evo jedne vrlo važne tačke – šta učiniti ako ne upravljate mrežom data centara, ali ste telekom operater? Ovo je i vaš problem: počevši od određenih verzija Junipera i Ariste, oni podrazumevano uključuju oznaku toka u svoje hash funkcije - iskreno, iz razloga koji mi nije jasan. Ovo može uzrokovati da prekinete TCP veze od korisnika koji prolaze kroz vašu mrežu. Stoga toplo preporučujem da ovdje provjerite postavke rutera.
Na ovaj ili onaj način, čini mi se da smo spremni da pređemo na eksperimente.
Kada smo omogućili oznaku toka na ToR-u, pripremili eBPF agent, koji sada živi na hostovima, odlučili smo da ne čekamo sljedeći veliki kvar, već da provodimo kontrolirane eksplozije. Uzeli smo ToR, koji ima četiri uplinka, i postavili dropove na jednom od njih. Izvukli su pravilo i rekli - sada gubite sve pakete. Kao što vidite na lijevoj strani, imamo nadzor po paketu, koji je pao na 75%, odnosno 25% paketa je izgubljeno. Na desnoj strani su grafikoni službi koje žive iza ovog zadatka. U suštini, ovo su grafovi saobraćaja interfejsa sa serverima unutar rack-a. Kao što vidite, potonule su još niže. Zašto su pali niže - ne za 25%, već u nekim slučajevima i 3-4 puta? Ako TCP veza nije srećna, nastavlja da pokušava da dopre kroz pokvareni spoj. Ovo je pogoršano tipičnim ponašanjem usluge unutar DC-a - za jedan korisnički zahtjev, generira se N zahtjeva za interne usluge, a odgovor će ići korisniku ili kada svi izvori podataka odgovore, ili kada dođe do isteka vremena u aplikaciji nivo, koji još treba da se konfiguriše. Odnosno, sve je jako, veoma loše.
Sada isti eksperiment, ali sa omogućenom vrijednošću oznake toka. Kao što vidite, na lijevoj strani naš nadzor serije je pao za istih 25%. To je apsolutno tačno, jer ne zna ništa o retransmitu, šalje pakete i jednostavno broji odnos broja isporučenih i izgubljenih paketa.
A sa desne strane je raspored servisa. Ovdje nećete naći efekte problematičnog zgloba. U tim istim milisekundama, saobraćaj je tekao iz problematične oblasti do tri preostale uzlazne veze na koje problem nije uticao. Imamo mrežu koja se sama liječi.
Ovo je moj posljednji slajd, vrijeme je da sumiram. Sada se nadam da znate kako da izgradite mrežu data centara koja se samoizlečuje. Nećete morati da prolazite kroz arhivu Linux kernela i da tamo tražite posebne zakrpe; znate da oznaka Flow u ovom slučaju rešava problem, ali ovom mehanizmu morate pažljivo pristupiti. I još jednom naglašavam da ako ste telekom operater, ne biste trebali koristiti oznaku toka kao hash funkciju, inače ćete poremetiti sesije vaših korisnika.
Mrežni inženjeri moraju proći kroz konceptualnu promjenu: mreža počinje ne sa ToR-om, ne sa mrežnim uređajem, već s hostom. Prilično upečatljiv primjer je kako koristimo eBPF i da promijenimo RTO i da popravimo oznaku toka prema uslugama anycast.
Mehanika oznaka protoka je svakako prikladna za druge primjene unutar kontroliranog administrativnog segmenta. To može biti promet između podatkovnih centara ili možete koristiti takvu mehaniku na poseban način za upravljanje odlaznim prometom. Ali o tome ću vam, nadam se, reći sljedeći put. Hvala vam puno na pažnji.
izvor: www.habr.com