Sodobni podatkovni centri imajo na stotine aktivnih naprav, ki jih pokrivajo različne vrste nadzora. Toda tudi popoln inženir s popolnim nadzorom v roki se bo lahko pravilno odzval na okvaro omrežja v le nekaj minutah. V poročilu na konferenci Next Hop 2020 sem predstavil metodologijo zasnove omrežja podatkovnih centrov, ki ima edinstveno lastnost – podatkovni center se sam popravi v milisekundah. Natančneje, inženir mirno odpravi težavo, servisi pa tega enostavno ne opazijo.
Za mnoge omrežne inženirje se omrežje podatkovnega centra seveda začne s ToR, s stikalom v omari. ToR ima običajno dve vrsti povezav. Malčki gredo na strežnike, drugi - teh je N-krat več - proti hrbtenici prvega nivoja, torej na njegove uplinke. Navzgornje povezave se običajno obravnavajo kot enake, promet med navzgornjimi povezavami pa je uravnotežen na podlagi 5-torne zgoščene vrednosti, ki vključuje proto, src_ip, dst_ip, src_port, dst_port. Tukaj ni presenečenj.
Nato, kako je videti arhitektura letal? Trne prvega nivoja med seboj niso povezane, ampak so povezane s superspini. Črka X bo odgovorna za superspine, je skoraj kot navzkrižna povezava.
In jasno je, da so po drugi strani tori povezani z vsemi hrbtenicami prve stopnje. Kaj je pomembno na tej sliki? Če imamo interakcijo znotraj stojala, potem interakcija seveda poteka skozi ToR. Če gre interakcija znotraj modula, potem gre interakcija skozi hrbtenice prve ravni. Če je interakcija intermodularna - kot tukaj, ToR 1 in ToR 2 - potem bo interakcija potekala skozi trne tako prve kot druge ravni.
Teoretično je takšna arhitektura enostavno nadgradljiva. Če imamo zmogljivost vrat, rezervo prostora v podatkovnem centru in vnaprej položeno vlakno, potem lahko število ravnin vedno povečamo in s tem povečamo skupno zmogljivost sistema. Na papirju je to zelo enostavno narediti. Tako bi bilo tudi v resničnem življenju. Toda današnja zgodba ne govori o tem.
Želim, da pride do pravilnih zaključkov. V podatkovnem centru imamo veliko poti. So pogojno samostojni. Ena pot znotraj podatkovnega centra je mogoča samo znotraj ToR. Znotraj modula imamo enako število poti kot je število ravnin. Število poti med moduli je enako produktu števila ravnin in števila superspinov v vsaki ravnini. Da bi bilo bolj jasno, da bi občutili lestvico, bom navedel številke, ki veljajo za enega od podatkovnih centrov Yandex.
Obstaja osem letal, vsako letalo ima 32 superspinov. Posledično se izkaže, da je znotraj modula osem poti, z medmodulno interakcijo pa jih je že 256.
To pomeni, da če razvijamo kuharsko knjigo in se poskušamo naučiti, kako zgraditi podatkovne centre, odporne na napake, ki se zdravijo sami, potem je planarna arhitektura prava izbira. Omogoča vam, da rešite problem skaliranja in teoretično je enostavno. Samostojnih poti je veliko. Vprašanje ostaja: kako takšna arhitektura preživi neuspehe? Obstajajo različni zrušitve. In o tem bomo zdaj razpravljali.
Naj zboli eden od naših superspinov. Tu sem se vrnil k arhitekturi dveh ravnin. Držali se jih bomo kot primer, ker bomo z manj gibljivimi deli preprosto lažje videli, kaj se tukaj dogaja. Naj X11 zboli. Kako bo to vplivalo na storitve, ki živijo v podatkovnih centrih? Veliko je odvisno od tega, kako je neuspeh dejansko videti.
Če je napaka dobra, se ujame na ravni avtomatizacije istega BFD, avtomatizacija z veseljem postavi problematične sklepe in izolira težavo, potem je vse v redu. Imamo veliko poti, promet se takoj preusmeri na alternativne poti, službe pa ne bodo opazile ničesar. To je dober scenarij.
Slab scenarij je, če imamo stalne izgube, avtomatika pa težave ne opazi. Da bi razumeli, kako to vpliva na aplikacijo, bomo morali posvetiti nekaj časa razpravi o delovanju protokola TCP.
Upam, da s to informacijo ne bom nikogar šokiral: TCP je protokol rokovanja. To pomeni, da v najpreprostejšem primeru pošiljatelj pošlje dva paketa in zanje prejme kumulativno potrdilo: "Prejel sem dva paketa."
Po tem bo poslal še dva paketa in situacija se bo ponovila. Že vnaprej se opravičujem za nekaj poenostavitve. Ta scenarij je pravilen, če je okno (število paketov v letu) dva. Seveda na splošno ni nujno tako. Toda velikost okna ne vpliva na kontekst posredovanja paketov.
Kaj se zgodi, če izgubimo paket 3? V tem primeru bo prejemnik prejel pakete 1, 2 in 4. Pošiljatelja pa bo z možnostjo SACK izrecno obvestil: »Veš, prišli so trije, srednji pa je izgubljen.« Pravi "Ack 2, SACK 4".
Pošiljatelj v tem trenutku brez težav ponovi točno tisti paket, ki je bil izgubljen.
Če pa se zadnji paket v oknu izgubi, bo situacija videti zelo drugačna.
Prejemnik prejme prve tri pakete in najprej začne čakati. Zahvaljujoč nekaterim optimizacijam v skladu TCP jedra Linuxa bo čakal na seznanjen paket, razen če v zastavicah ni izrecne navedbe, da je to zadnji paket ali kaj podobnega. Počakal bo, dokler ne poteče časovna omejitev zakasnjenega ACK, nato pa bo poslal potrditev za prve tri pakete. Zdaj pa bo pošiljatelj čakal. Ne ve, ali se je četrti paket izgubil ali bo kmalu prišel. In da ne bi preobremenili omrežja, bo poskušal počakati na izrecno navedbo, da je paket izgubljen, ali na potek časovne omejitve RTO.
Kaj je časovna omejitev RTO? To je največ iz RTT, izračunanega s skladom TCP in nekaj konstante. Kaj je ta konstanta, bomo zdaj razpravljali.
Je pa pomembno, da če spet nimamo sreče in se četrti paket spet izgubi, potem se RTO podvoji. To pomeni, da je vsak neuspešen poskus podvojitev časovne omejitve.
Zdaj pa poglejmo, čemu je ta osnova enaka. Privzeto je najmanjši RTO 200 ms. To je najmanjši RTO za podatkovne pakete. Za pakete SYN je drugačen, 1 sekunda. Kot lahko vidite, bo celo prvi poskus ponovnega pošiljanja paketov trajal 100-krat dlje kot RTT znotraj podatkovnega centra.
Zdaj pa nazaj k našemu scenariju. Kaj se dogaja s storitvijo? Storitev začne izgubljati pakete. Naj ima storitev na začetku srečo in nekaj izgubi na sredini okna, potem prejme SACK, ponovno pošlje izgubljene pakete.
Če pa se smola ponovi, potem imamo RTO. Kaj je tukaj pomembno? Da, v omrežju imamo veliko poti. Toda promet TCP ene določene povezave TCP bo še naprej šel skozi isti pokvarjen sklad. Izguba paketov, pod pogojem, da naš čarobni X11 ne ugasne sam, ne povzroči pretoka prometa na območja, ki niso problematična. Poskušamo dostaviti paket prek istega pokvarjenega sklada. To vodi do kaskadne okvare: podatkovni center je niz medsebojno delujočih aplikacij in nekatere povezave TCP vseh teh aplikacij se začnejo slabšati - ker superspin vpliva na vse aplikacije, ki so znotraj DC. Kot v pregovoru: če konja ne podkuješ, konj šepa; konj je šepal - poročilo ni bilo oddano; sporočilo ni bilo predano - izgubili so vojno. Samo tukaj se šteje sekunde od trenutka, ko se pojavi težava, do stopnje degradacije, ki jo storitve začnejo čutiti. To pomeni, da uporabniki nekje nečesa ne bodo prejeli.
Obstajata dve klasični rešitvi, ki se dopolnjujeta. Prvi so storitve, ki poskušajo polagati slamico in rešiti težavo takole: »Popravimo nekaj v TCP stacku. In naredimo časovne omejitve na ravni aplikacije ali dolgotrajne seje TCP z notranjimi pregledi zdravja. Težava je v tem, da takšne rešitve: a) sploh niso merilne; b) zelo slabo testiran. To pomeni, da tudi če storitev pomotoma konfigurira sklad TCP, tako da postane boljši, prvič, to verjetno ne bo veljalo za vse aplikacije in vse podatkovne centre, in drugič, najverjetneje ne bo razumel, kaj je bilo narejeno pravilno in kaj ne. To pomeni, da deluje, vendar deluje slabo in se ne spreminja. In če pride do težave z omrežjem, kdo je kriv? Seveda NOC. Kaj počne NOC?
Številne službe verjamejo, da v NOC delo poteka nekako tako. A če sem iskren, ne samo.
NOC v klasični shemi se ukvarja z razvojem številnih monitoringov. To sta tako spremljanje črne skrinjice kot spremljanje bele skrinjice. O primeru črne skrinjice-monitoringa bodic Aleksander Klimenko o preteklem Next Hopu. Mimogrede, to spremljanje deluje. Toda tudi popolno spremljanje bo imelo časovni zamik. Ponavadi je nekaj minut. Ko deluje, potrebujejo dežurni inženirji čas, da ponovno preverijo njegovo delovanje, lokalizirajo težavo in nato pogasijo problematično območje. Se pravi, v najboljšem primeru zdravljenje problema traja 5 minut, v najslabšem 20 minut, če ni takoj razvidno, kje so izgube. Jasno je, da bodo ves ta čas - 5 ali 20 minut - naše storitve še naprej bolele, kar verjetno ni dobro.
Kaj bi radi prejeli? Toliko poti imamo. In težave nastanejo prav zato, ker tokovi TCP, ki nimajo sreče, še naprej uporabljajo isto pot. Potrebujemo nekaj, kar nam bo omogočilo uporabo več poti znotraj ene povezave TCP. Zdi se, da imamo rešitev. Obstaja TCP, ki se imenuje tako - multipath TCP, to je TCP za številne poti. Res je, da je bil razvit za povsem drugo nalogo - za pametne telefone, ki imajo več omrežnih naprav. Da bi povečali prenos ali naredili primarni / rezervni način, je bil razvit mehanizem, ki pregledno ustvari več niti (sej) za aplikacijo in vam omogoča preklapljanje med njimi v primeru okvare. Ali, kot sem rekel, povečajte pasovno širino.
Toda tukaj je odtenek. Da bi razumeli, kaj je to, si bomo morali ogledati, kako so nastavljeni tokovi.
Niti so nastavljene zaporedno. Najprej se namesti prvi tok. Naslednji tokovi se nato nastavijo z uporabo piškotka, ki je že dogovorjen znotraj te niti. In tukaj je problem.
Težava je v tem, da če se prva nit ne namesti, se druga in tretja nit nikoli ne prikažeta. To pomeni, da večpotni TCP ne reši izgube paketa SYN v prvem toku. In če se SYN izgubi, večpotni TCP postane običajni TCP. V okolju podatkovnega centra nam torej ne bo pomagalo rešiti problema izgub v tovarni in se naučiti uporabljati več poti v primeru okvare.
Kaj nam lahko pomaga? Nekateri ste že iz imena uganili, da bo polje glave oznake toka IPv6 pomembno polje v naši nadaljnji zgodbi. Dejansko je to polje, ki se pojavlja v različici 6, ni pa v različici 4, traja 20 bitov, o njegovi uporabi pa že dolgo potekajo polemike. To je zelo zanimivo - prišlo je do sporov, nekaj je bilo popravljeno v okviru RFC, hkrati pa se je v jedru Linuxa pojavila implementacija, ki ni bila nikoli nikjer dokumentirana.
Predlagam, da se mi pridružite pri majhni raziskavi. Oglejmo si, kaj se je dogajalo v jedru Linuxa v zadnjih nekaj letih.
leto 2014. Inženir iz velikega in uglednega podjetja doda funkcionalnosti jedra Linuxa odvisnost vrednosti oznake toka od zgoščene vrednosti vtičnice. Kaj poskušajo popraviti tukaj? To je povezano z RFC 6438, ki obravnava naslednjo težavo. Znotraj podatkovnega centra je IPv4 pogosto enkapsuliran v pakete IPv6, ker je sama tovarna IPv6, vendar mora biti IPv4 nekako oddan. Dolgo časa so bile težave s stikali, ki niso mogla pogledati pod dve glavi IP, da bi prišla do TCP ali UDP in tam poiskala src_ports, dst_ports. Izkazalo se je, da se je hash, če pogledate prvi dve glavi IP, skoraj popravil. Da bi se temu izognili in da bi uravnoteženje tega enkapsuliranega prometa delovalo pravilno, je bilo predlagano, da se vrednosti polja oznake toka doda zgoščena vrednost iz enkapsuliranega paketa s 5 dvojkami. Približno enako je bilo narejeno za druge sheme enkapsulacije, za UDP, za GRE, pri slednjem je bilo uporabljeno polje GRE Key. Tako ali drugače so cilji tukaj jasni. In vsaj v tistem trenutku so bili uporabni.
Leta 2015 nov popravek prihaja od istega cenjenega inženirja. Je zelo zanimiv. Piše naslednje - v primeru negativnega dogodka usmerjanja bomo naključno razvrstili zgoščeno vrednost. Kaj je negativni usmerjevalni dogodek? To je RTO, o katerem smo razpravljali prej, to je izguba okenskega repa dogodek, ki je res negativen. Res je, razmeroma težko je uganiti, za kaj gre.
2016, še eno cenjeno podjetje, tudi veliko. Razčleni zadnje bergle in naredi tako, da se hash, ki smo ga prej naredili naključno, zdaj spremeni ob vsakem ponovnem prenosu SYN in po vsaki časovni omejitvi RTO. In v tem pismu se prvič in zadnjič sliši končni cilj - zagotoviti, da ima promet v primeru izgube ali preobremenjenosti kanalov možnost mehke preusmeritve z uporabo več poti. Seveda je bilo po tem veliko publikacij, zlahka jih najdete.
Čeprav ne, ne morete, ker na to temo ni bilo niti ene objave. Ampak vemo!
In če ne razumete popolnoma, kaj je bilo storjeno, vam bom zdaj povedal.
Kaj je bilo narejenega, katere funkcije so bile dodane jedru Linuxa? txhash se po vsakem dogodku RTO spremeni v naključno vrednost. To je isti negativni rezultat usmerjanja. Zgoščena vrednost je odvisna od te razpršilne vrednosti txhash in oznaka toka je odvisna od zgoščene vrednosti skb. Tukaj je nekaj izračunov funkcij, vseh podrobnosti ni mogoče dati na en diapozitiv. Če je kdo radoveden, lahko pregleda kodo jedra in preveri.
Kaj je tukaj pomembno? Vrednost polja oznake toka se po vsakem RTO spremeni v naključno število. Kako to vpliva na naš nesrečni tok TCP?
V primeru SACK se ni nič spremenilo, ker poskušamo znova poslati znani izgubljeni paket. Zaenkrat gre dobro.
Toda v primeru RTO, pod pogojem, da smo dodali oznako toka zgoščevalni funkciji na ToR, lahko promet poteka po drugi poti. In več kot je ravnin, večja je verjetnost, da boste našli pot, na katero ne vpliva strmoglavljenje določene naprave.
Ena težava ostaja - RTO. Druga pot se seveda najde, vendar se na njej porabi veliko časa. 200ms je veliko. Drugi je na splošno divjina. Prej sem govoril o časovnih omejitvah, ki konfigurirajo storitve. Sekunda je torej časovna omejitev, ki običajno vzpostavi storitev na nivoju aplikacije in v tem bo storitev celo razmeroma prava. Še več, ponavljam, pravi RTT v sodobnem podatkovnem centru je približno 1 milisekunda.
Kaj je mogoče storiti glede časovnih omejitev RTO? Časovno omejitev, ki je odgovorna za RTO v primeru izgube podatkovnih paketov, je mogoče relativno enostavno konfigurirati iz uporabniškega prostora: obstaja pripomoček IP in eden od njegovih parametrov vsebuje isti rto_min. Glede na to, da seveda morate RTO obrniti ne globalno, ampak za dane predpone, je tak mehanizem videti precej delujoč.
Res je, s SYN_RTO je vse nekoliko slabše. Je naravno pribito. Vrednost je fiksna v jedru - 1 sekunda, in to je to. Ne morete ga doseči iz uporabniškega prostora. Pot je samo ena.
eBPF priskoči na pomoč. Če poenostavimo, so to majhni programi C. Lahko jih vstavimo v hooke na različnih mestih v izvajanju sklada jedra in sklada TCP, s katerimi lahko spremenimo zelo veliko nastavitev. Na splošno je eBPF dolgoročen trend. Namesto zmanjšanja na desetine novih parametrov sysctl in razširitve pripomočka IP gre gibanje v smeri eBPF in razširitve njegove funkcionalnosti. Z eBPF lahko dinamično spreminjate nadzor zastojev in različne druge nastavitve TCP.
Toda za nas je pomembno, da lahko s pomočjo tega zavrtite vrednosti SYN_RTO. In tam je javno objavljen primer: . Kaj se dela tukaj? Primer deluje, vendar je sam po sebi zelo grob. Tukaj se predpostavlja, da znotraj podatkovnega centra primerjamo prvih 44 bitov, če se ujemajo, potem se znajdemo znotraj DC. In v tem primeru spremenimo vrednost časovne omejitve SYN_RTO na 4 ms. Isto nalogo je mogoče opraviti veliko bolj elegantno. Toda ta preprost primer kaže, kaj je a) mogoče; b) razmeroma enostavno.
Kaj že vemo? Da planarna arhitektura omogoča skaliranje, se izkaže za izjemno uporabno za nas, ko na ToR vklopimo oznako toka in dobimo možnost toka okoli problematičnih področij. Najboljši način za znižanje vrednosti RTO in SYN-RTO je uporaba programov eBPF. Vprašanje ostaja: ali je varno uporabljati oznako pretoka za uravnoteženje? In tu je odtenek.
Recimo, da imate storitev v omrežju, ki živi v anycast. Na žalost nimam časa, da bi se spuščal v podrobnosti o anycastu, vendar je to porazdeljena storitev, kjer so na istem naslovu IP na voljo različni fizični strežniki. In tukaj je možna težava: dogodek RTO se lahko pojavi ne samo, ko promet poteka skozi tovarno. Lahko se pojavi tudi na ravni medpomnilnika ToR: ko pride do dogodka incast, se lahko zgodi celo na gostitelju, ko gostitelj nekaj razlije. Ko pride do dogodka RTO in spremeni oznako toka. V tem primeru gre lahko promet na drugo instanco anycast. Recimo, da gre za anycast s stanjem, vsebuje stanje povezave - lahko je L3 Balancer ali kakšna druga storitev. Potem nastane problem, ker po RTO pride TCP povezava do strežnika, ki o tej TCP povezavi ne ve nič. In če nimamo deljenja stanja med strežniki anycast, bo tak promet opuščen in povezava TCP bo prekinjena.
Kaj se tukaj da narediti? Znotraj vašega nadzorovanega okolja, kjer omogočite uravnoteženje oznake toka, morate popraviti vrednost oznake toka pri dostopu do strežnikov anycast. Najlažji način je, da to storite prek istega programa eBPF. Toda tukaj je zelo pomembna točka - kaj storiti, če ne upravljate omrežja podatkovnega centra, ampak ste telekomunikacijski operater? To je tudi vaša težava: začenši z določenimi različicami programov Juniper in Arista privzeto vključita oznako toka v funkcijo zgoščevanja - če sem iskren, iz razloga, ki ga ne razumem. To lahko povzroči prekinitev povezav TCP uporabnikov, ki gredo skozi vaše omrežje. Zato toplo priporočam, da preverite nastavitve usmerjevalnika na tej lokaciji.
Tako ali drugače se mi zdi, da smo pripravljeni preiti na poskuse.
Ko smo vklopili oznako toka na ToR, pripravili agentov eBPF, ki zdaj živi na gostiteljih, smo se odločili, da ne bomo čakali na naslednjo veliko napako, ampak bomo izvajali nadzorovane eksplozije. Vzeli smo ToR, ki ima štiri navzgornje povezave, in naredili padce na enem od njih. Narisali so pravilo, rekli so - zdaj izgubiš vse pakete. Kot lahko vidite na levi, imamo nadzor paketov, ki se je zmanjšal na 75 %, kar pomeni, da se izgubi 25 % paketov. Na desni so grafi storitev, ki živijo za tem ToR. Pravzaprav so to prometni grafi spojev s strežniki v omari. Kot vidite, so potonili še nižje. Zakaj so potonili nižje - ne za 25%, ampak v nekaterih primerih za 3-4 krat? Če povezava TCP ni uspešna, še naprej poskuša doseči prek okvarjenega vmesnika. To je še poslabšano zaradi tipičnega vedenja storitve znotraj DC - za eno uporabniško zahtevo se ustvari N zahtev za notranje storitve, odgovor pa bo šel uporabniku, bodisi ko se odzovejo vsi viri podatkov ali ko se sproži časovna omejitev ob ravni aplikacije, ki jo je treba še konfigurirati. Se pravi, vse je zelo, zelo slabo.
Zdaj isti poskus, vendar z omogočeno oznako toka. Kot lahko vidite, je na levi strani naš nadzor serije potonil za istih 25 %. To je popolnoma pravilno, saj ne ve ničesar o ponovnih pošiljanjih, pošilja pakete in preprosto šteje razmerje med številom dostavljenih in izgubljenih paketov.
In na desni je urnik storitev. Tukaj ne boste našli učinka problematičnega sklepa. Promet je v istih milisekundah stekel od problematičnega območja do treh preostalih navzgornjih povezav, na katere težava ni vplivala. Imamo mrežo, ki se zdravi sama.
To je moj zadnji diapozitiv, čas za pregled. Upam, da veste, kako zgraditi samopopravljalno omrežje podatkovnega centra. Ne bo vam treba brskati po arhivu jedra Linuxa in tam iskati posebnih popravkov, veste, da oznaka Flow v tem primeru reši težavo, vendar morate k temu mehanizmu pristopiti previdno. In še enkrat poudarjam, da če ste nosilec, ne smete uporabljati oznake toka kot zgoščevalne funkcije, sicer boste prekinili seje svojih uporabnikov.
Za omrežne inženirje se mora zgoditi konceptualni premik: omrežje se ne začne s ToR, ne z omrežno napravo, ampak z gostiteljem. Precej osupljiv primer je, kako uporabljamo eBPF za spreminjanje RTO in za popravljanje oznake toka proti storitvam anycast.
Mehanik etikete toka je vsekakor primeren tudi za druge namene znotraj nadzorovanega administrativnega segmenta. To je lahko promet med podatkovnimi centri ali pa takšno mehaniko uporabite na poseben način za nadzor odhodnega prometa. Bom pa o tem, upam, drugič. Najlepša hvala za vašo pozornost.
Vir: www.habr.com