ProHoster > Blogs > Administrācija > Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

MÅ«sdienu datu centros ir simtiem aktÄ«vo ierīču, uz kurām attiecas dažādi uzraudzÄ«bas veidi. Bet pat ideāls inženieris ar perfektu uzraudzÄ«bu spēs pareizi reaģēt uz tÄ«kla kļūmi tikai dažu minÅ«Å”u laikā. Ziņojumā Next Hop 2020 konferencē es prezentēju datu centra tÄ«kla projektÄ“Å”anas metodoloÄ£iju, kurai ir unikāla iezÄ«me - datu centrs atveseļojas pats par sevi milisekundēs. PrecÄ«zāk, inženieris mierÄ«gi novērÅ” problēmu, savukārt dienesti to vienkārÅ”i nepamana.

- Sākumā es sniegÅ”u diezgan detalizētu ievadu tiem, kuri, iespējams, nav informēti par mÅ«sdienu DC uzbÅ«vi.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Daudziem tÄ«kla inženieriem datu centru tÄ«kls, protams, sākas ar ToR, ar slēdzi plauktā. ToR parasti ir divu veidu saites. Mazie iet uz serveriem, citi - viņu ir N reizes vairāk - iet uz pirmā lÄ«meņa spines, tas ir, uz tās uplinkiem. AugÅ”upsaites parasti tiek uzskatÄ«tas par vienādām, un datplÅ«sma starp augÅ”upsaitēm tiek lÄ«dzsvarota, pamatojoties uz 5 korpusu jaucējkodu, kas ietver proto, src_ip, dst_ip, src_port, dst_port. Å eit nav nekādu pārsteigumu.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Tālāk, kā izskatās lidmaŔīnu arhitektÅ«ra? Pirmā lÄ«meņa muguriņas nav savienotas viena ar otru, bet ir savienotas ar superspinu palÄ«dzÄ«bu. Burts X bÅ«s atbildÄ«gs par superspiniem, tas ir gandrÄ«z kā Ŕķērssavienojums.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Un ir skaidrs, ka, no otras puses, tori ir savienoti ar visiem pirmā lÄ«meņa muguriņiem. Kas Å”ajā attēlā ir svarÄ«gs? Ja mums ir mijiedarbÄ«ba plauktā, tad mijiedarbÄ«ba, protams, notiek caur ToR. Ja mijiedarbÄ«ba notiek moduļa iekÅ”ienē, tad mijiedarbÄ«ba notiek caur pirmā lÄ«meņa muguriņām. Ja mijiedarbÄ«ba ir starpmodulāra - kā Å”eit, ToR 1 un ToR 2 -, tad mijiedarbÄ«ba iet cauri gan pirmā, gan otrā lÄ«meņa mugurkaulam.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Teorētiski Ŕāda arhitektÅ«ra ir viegli mērogojama. Ja mums ir porta ietilpÄ«ba, vietas rezerve datu centrā un iepriekÅ” ieklāta Ŕķiedra, tad plakņu skaitu vienmēr var palielināt, tādējādi palielinot sistēmas kopējo kapacitāti. Uz papÄ«ra tas ir ļoti vienkārÅ”i izdarāms. Tā tas bÅ«tu arÄ« reālajā dzÄ«vē. Bet Å”odienas stāsts nav par to.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Es gribu, lai tiktu izdarÄ«ti pareizi secinājumi. Mums ir daudz ceļu datu centrā. Viņi ir nosacÄ«ti neatkarÄ«gi. Viens veids, kā iekļūt datu centrā, ir iespējams tikai ToR ietvaros. Moduļa iekÅ”pusē mums ir tāds pats ceļu skaits kā plakņu skaits. Ceļu skaits starp moduļiem ir vienāds ar plakņu skaita un supergriezienu skaita reizinājumu katrā plaknē. Lai bÅ«tu skaidrāk, lai sajustu mērogu, nosaukÅ”u skaitļus, kas ir derÄ«gi kādam no Yandex datu centriem.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ir astoņas lidmaŔīnas, katrai lidmaŔīnai ir 32 supergriezieni. Rezultātā izrādās, ka moduļa iekÅ”pusē ir astoņi ceļi, un ar starpmoduļu mijiedarbÄ«bu no tiem jau ir 256.

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Tas ir, ja mēs izstrādājam pavārgrāmatu, mēģinot uzzināt, kā izveidot defektu izturÄ«gus datu centrus, kas paÅ”i sevi dziedē, tad plakanā arhitektÅ«ra ir pareizā izvēle. Tas ļauj atrisināt mērogoÅ”anas problēmu, un teorētiski tas ir viegli. Ir daudz neatkarÄ«gu ceļu. Paliek jautājums: kā Ŕāda arhitektÅ«ra pārdzÄ«vo neveiksmes? Notiek dažādas avārijas. Un mēs to tagad apspriedÄ«sim.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Lai kāds no mÅ«su superspiniem saslimst. Å eit es atgriezos pie divu plakņu arhitektÅ«ras. Mēs pieturēsimies pie tiem kā piemēra, jo vienkārÅ”i bÅ«s vieglāk redzēt, kas Å”eit notiek, ja ir mazāk kustÄ«go daļu. Lai X11 saslimst. Kā tas ietekmēs pakalpojumus, kas dzÄ«vo datu centros? Daudz kas ir atkarÄ«gs no tā, kā patiesÄ«bā izskatās neveiksme.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ja kļūme ir laba, tā tiek noÄ·erta tā paÅ”a BFD automatizācijas lÄ«menÄ«, automatizācija ar prieku liek problēmsavienojumus un izolē problēmu, tad viss ir kārtÄ«bā. Mums ir daudz ceļu, satiksme momentāni tiek novirzÄ«ta uz alternatÄ«viem marÅ”rutiem, un dienesti neko nepamanÄ«s. Å is ir labs scenārijs.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Slikts scenārijs ir tad, ja mums ir pastāvīgi zaudējumi un automatizācija nepamana problēmu. Lai saprastu, kā tas ietekmē lietojumprogrammu, mums būs jāpavada nedaudz laika, lai apspriestu, kā darbojas TCP protokols.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ceru, ka ar Å”o informāciju nevienu neÅ”okÄ“Å”u: TCP ir rokasspiediena protokols. Tas ir, vienkārŔākajā gadÄ«jumā sÅ«tÄ«tājs nosÅ«ta divas paketes un saņem kumulatÄ«vu apstiprinājumu par tām: "Es saņēmu divas paketes."
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Pēc tam viņŔ nosÅ«tÄ«s vēl divas paketes, un situācija atkārtosies. Jau iepriekÅ” atvainojos par nelielu vienkārÅ”oÅ”anu. Å is scenārijs ir pareizs, ja logs (pakeÅ”u skaits lidojumā) ir divi. Protams, kopumā tas tā nav obligāti. Bet pakeÅ”u pārsÅ«tÄ«Å”anas kontekstu neietekmē loga lielums.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Kas notiks, ja mēs pazaudēsim 3. paku? Å ajā gadÄ«jumā adresāts saņems 1., 2. un 4. paciņas. Un viņŔ, izmantojot opciju SACK, skaidri informēs sÅ«tÄ«tāju: "Zini, atnāca trÄ«s, bet pazaudēja vidējo." ViņŔ saka "Ack 2, SACK 4".
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

SÅ«tÄ«tājs Å”ajā brÄ«dÄ« bez problēmām atkārto tieÅ”i pazaudēto paketi.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Bet, ja logā tiek pazaudēta pēdējā pakete, situācija izskatīsies pavisam savādāk.

Saņēmējs saņem pirmās trÄ«s paketes un vispirms sāk gaidÄ«t. Pateicoties dažām optimizācijām Linux kodola TCP stekā, tas gaidÄ«s pārÄ« savienotu paketi, ja vien karogos nav skaidri norādÄ«ts, ka Ŕī ir pēdējā pakete vai tamlÄ«dzÄ«gi. Tas gaidÄ«s, lÄ«dz beidzas aizkavētā ACK taimauts, un pēc tam nosÅ«tÄ«s apstiprinājumu par pirmajām trim paketēm. Bet tagad sÅ«tÄ«tājs gaidÄ«s. ViņŔ nezina, vai ceturtā paka ir pazudusi vai gatavojas ierasties. Un, lai nepārslogotu tÄ«klu, tas mēģinās gaidÄ«t skaidru norādi, ka pakete ir pazaudēta, vai RTO taimauta beigas.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Kas ir RTO taimauts? Tas ir maksimums no RTT, ko aprēķina TCP steka un kāda konstante. Kas ir Ŕī konstante, mēs tagad apspriedÄ«sim.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Bet svarÄ«gi, ja atkal nepaveicas un atkal tiek pazaudēta ceturtā pakete, tad RTO dubultojas. Tas nozÄ«mē, ka katrs neveiksmÄ«gs mēģinājums ir taimauta dubultoÅ”anās.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Tagad redzēsim, ar ko Ŕī bāze ir vienāda. Pēc noklusējuma minimālais RTO ir 200 ms. Tas ir minimālais datu pakeÅ”u RTO. SYN paketēm tas ir atŔķirÄ«gs, 1 sekunde. Kā redzat, pat pirmais mēģinājums atkārtoti nosÅ«tÄ«t paketes prasÄ«s 100 reizes ilgāk nekā RTT datu centrā.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Tagad atgriezieties pie mūsu scenārija. Kas notiek ar pakalpojumu? Pakalpojums sāk zaudēt paketes. Lai servisam sākotnēji paveicas un pazaudē kaut ko loga vidū, tad saņem MAISU, nosūta pazaudētās paketes vēlreiz.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Bet, ja nelaime atkārtojas, tad mums ir RTO. Kas Å”eit ir svarÄ«gs? Jā, tÄ«klā mums ir daudz ceļu. Taču viena konkrēta TCP savienojuma TCP trafiks turpinās iet caur to paÅ”u bojāto steku. PakeÅ”u zudums, ja mÅ«su maÄ£iskais X11 neizdziest pats no sevis, nenoved pie satiksmes plÅ«smas uz vietām, kas nav problemātiskas. Mēs cenÅ”amies piegādāt paketi caur to paÅ”u bojāto kaudzÄ«ti. Tas noved pie kaskādes kļūmes: datu centrs ir mijiedarbojoÅ”u lietojumprogrammu kopums, un daži visu Å”o lietojumprogrammu TCP savienojumi sāk bojāties, jo superspin ietekmē visas lietojumprogrammas, kas atrodas datu centrā. Kā teicienā: ja zirgu neapapē, zirgs klibo; zirgs kliboja - ziņojums netika piegādāts; ziņa netika nodota - viņi zaudēja karu. Tikai Å”eit skaitÄ«Å”ana ilgst sekundes no brīža, kad problēma rodas, lÄ«dz degradācijas stadijai, ko sāk izjust pakalpojumi. Tas nozÄ«mē, ka lietotāji kaut kur var kaut ko nesaņemt.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ir divi klasiski risinājumi, kas viens otru papildina. Pirmais ir servisi, kas mēģina nolikt salmus un atrisināt problēmu Ŕādi: ā€œPielāgosim kaut ko TCP kaudzē. Un izveidosim lietojumprogrammas lÄ«meņa taimautus vai ilgstoÅ”as ā€‹ā€‹TCP sesijas ar iekŔējām veselÄ«bas pārbaudēm. Problēma ir tāda, ka Ŕādi risinājumi: a) vispār nav mērogoti; b) ļoti slikti pārbaudÄ«ts. Tas ir, pat ja pakalpojums nejauÅ”i konfigurē TCP steku, lai tas kļūtu labāks, pirmkārt, tas, visticamāk, nebÅ«s piemērojams visām lietojumprogrammām un visiem datu centriem, un, otrkārt, visticamāk, tas nesapratÄ«s, kas ir izdarÄ«ts pareizi un kas nē. Tas ir, tas darbojas, bet tas darbojas slikti un nesamazinās. Un, ja ir tÄ«kla problēma, kurÅ” ir vainÄ«gs? Protams, NOC. Ko dara NOC?

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Daudzi dienesti uzskata, ka NOC darbs notiek apmēram Ŕādi. Bet, godÄ«gi sakot, ne tikai.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

NOC klasiskajā shēmā nodarbojas ar daudzu monitoringu izstrādi. Tie ir gan melnās kastes uzraudzÄ«ba, gan baltās kastes uzraudzÄ«ba. Par muguriņu melnās kastes monitoringa piemēru stāstÄ«ja Aleksandrs Kļimenko par pagātni Next Hop. Starp citu, Ŕī uzraudzÄ«ba darbojas. Bet pat ideālai uzraudzÄ«bai bÅ«s laika nobÄ«de. Parasti tas ir vairākas minÅ«tes. Pēc tam, kad tas darbojas, dežurējoÅ”ajiem inženieriem ir nepiecieÅ”ams laiks, lai vēlreiz pārbaudÄ«tu tā darbÄ«bu, lokalizētu problēmu un pēc tam likvidētu problēmas zonu. Tas ir, labākajā gadÄ«jumā problēmas ārstÄ“Å”ana aizņem 5 minÅ«tes, sliktākajā gadÄ«jumā 20 minÅ«tes, ja nav uzreiz skaidrs, kur rodas zaudējumi. Skaidrs, ka visu Å”o laiku - 5 vai 20 minÅ«tes - mÅ«su dienesti turpinās sāpēt, kas, iespējams, nav labi.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ko tu vēlētos saņemt? Mums ir tik daudz ceļu. Un problēmas rodas tieÅ”i tāpēc, ka neveiksmÄ«gās TCP plÅ«smas turpina izmantot to paÅ”u marÅ”rutu. Mums ir nepiecieÅ”ams kaut kas, kas ļaus mums izmantot vairākus marÅ”rutus vienā TCP savienojumā. Å Ä·iet, ka mums ir risinājums. Ir TCP, ko sauc tā - vairāku ceļu TCP, tas ir, TCP daudziem ceļiem. Tiesa, tas tika izstrādāts pavisam citam uzdevumam ā€“ viedtālruņiem, kuriem ir vairākas tÄ«kla ierÄ«ces. Lai maksimāli palielinātu pārsÅ«tÄ«Å”anu vai izveidotu primāro / rezerves režīmu, tika izstrādāts mehānisms, kas lietojumprogrammai pārredzami izveido vairākus pavedienus (sesijas) un ļauj pārslēgties starp tiem kļūmes gadÄ«jumā. Vai, kā jau teicu, palieliniet joslas platumu.

Bet Ŕeit ir nianse. Lai saprastu, kas tas ir, mums ir jāaplūko, kā tiek iestatītas straumes.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

VÄ«tnes tiek iestatÄ«tas secÄ«gi. Vispirms tiek instalēta pirmā straume. Turpmākās plÅ«smas tiek iestatÄ«tas, izmantojot sÄ«kfailu, par kuru jau ir panākta vienoÅ”anās Å”ajā pavedienā. Un Å”eit ir problēma.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Problēma ir tāda, ka, ja pirmais pavediens netiek instalēts, otrais un treÅ”ais pavediens nekad netiks parādÄ«ts. Tas nozÄ«mē, ka daudzceļu TCP neatrisina SYN paketes zudumu pirmajā straumē. Un, ja SYN tiek zaudēts, daudzceļu TCP kļūst par normālu TCP. Tātad datu centra vidē tas mums nepalÄ«dzēs atrisināt problēmu ar zaudējumiem rÅ«pnÄ«cā un iemācÄ«ties izmantot vairākus ceļus neveiksmes gadÄ«jumā.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Kas mums var palÄ«dzēt? Daži no jums jau pēc nosaukuma ir uzminējuÅ”i, ka IPv6 plÅ«smas etiÄ·etes galvenes lauks bÅ«s svarÄ«gs lauks mÅ«su turpmākajā stāstā. PatieŔām, Å”is ir lauks, kas parādās versijā v6, tā nav v4, tas aizņem 20 bitus, un par tā izmantoÅ”anu ir bijuÅ”as domstarpÄ«bas jau ilgu laiku. Tas ir ļoti interesanti - bija strÄ«di, kaut kas tika labots RFC ietvaros, un tajā paŔā laikā Linux kodolā parādÄ«jās implementācija, kas nekad nekur netika dokumentēta.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Es iesaku pievienoties man nelielai izmeklÄ“Å”anai. ApskatÄ«sim, kas pēdējos gados ir noticis Linux kodolā.

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

2014. gads. Inženieris no liela un cienÄ«jama uzņēmuma Linux kodola funkcionalitāti papildina ar plÅ«smas etiÄ·etes vērtÄ«bas atkarÄ«bu no ligzdas hash. Ko viņi te cenÅ”as labot? Tas ir saistÄ«ts ar RFC 6438, kurā tika apspriesta Ŕāda problēma. Datu centra iekÅ”ienē IPv4 bieži ir iekapsulēts IPv6 paketēs, jo pati rÅ«pnÄ«ca ir IPv6, bet IPv4 kaut kā jāizdod. Ilgu laiku bija problēmas ar slēdžiem, kas nevarēja meklēt zem divām IP galvenēm, lai nokļūtu TCP vai UDP un atrastu tur src_ports, dst_ports. IzrādÄ«jās, ka hash, ja paskatās uz pirmajām divām IP galvenes, izrādÄ«jās gandrÄ«z fiksēts. Lai no tā izvairÄ«tos, lai Ŕīs iekapsulētās trafika lÄ«dzsvaroÅ”ana darbotos pareizi, tika ierosināts plÅ«smas etiÄ·etes lauka vērtÄ«bai pievienot jaucēju no 5 korpusa iekapsulētās paketes. Apmēram tas pats tika darÄ«ts citām iekapsulÄ“Å”anas shēmām, UDP, GRE, pēdējā tika izmantots lauks GRE Key. Tā vai citādi mērÄ·i Å”eit ir skaidri. Un vismaz tajā brÄ«dÄ« tie bija noderÄ«gi.

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

2015. gadā jauns ielāps nāk no tā paÅ”a cienÄ«jamā inženiera. ViņŔ ir ļoti interesants. Tur ir teikts sekojoÅ”ais ā€“ mēs nejauÅ”i izvēlēsimies jaucēju negatÄ«va marÅ”rutÄ“Å”anas notikuma gadÄ«jumā. Kas ir negatÄ«vs marÅ”rutÄ“Å”anas notikums? Å is ir RTO, par kuru mēs runājām iepriekÅ”, tas ir, loga astes zudums ir patieŔām negatÄ«vs notikums. Tiesa, ir salÄ«dzinoÅ”i grÅ«ti uzminēt, kas tas ir.

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

2016, vēl viens cienÄ«ts uzņēmums, arÄ« liels. Tas parsē pēdējos kruÄ·us un padara to tā, lai jaukÅ”ana, ko mēs iepriekÅ” veicām nejauÅ”i, tagad tiek mainÄ«ta katrā SYN atkārtotajā pārraidē un pēc katra RTO taimauta. Un Å”ajā vēstulē pirmo un pēdējo reizi izskan galvenais mērÄ·is - pārliecināties, ka trafika kanālu zuduma vai pārslodzes gadÄ«jumā ir iespēja veikt mÄ«kstu pārmarÅ”rutu, izmantojot vairākus ceļus. Protams, pēc tam bija daudz publikāciju, tās var viegli atrast.

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Lai gan nē, jÅ«s nevarat, jo par Å”o tēmu nav bijusi neviena publikācija. Bet mēs zinām!

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Un, ja jūs pilnībā nesaprotat, kas tika darīts, es jums pateikŔu tagad.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Kas ir paveikts, kāda funkcionalitāte ir pievienota Linux kodolam? txhash mainās uz nejauÅ”u vērtÄ«bu pēc katra RTO notikuma. Å is ir tas pats negatÄ«vais marÅ”rutÄ“Å”anas rezultāts. Jaucējs ir atkarÄ«gs no Ŕī txhash, un plÅ«smas etiÄ·ete ir atkarÄ«ga no skb jaucējkoda. Å eit ir daži aprēķini par funkcijām, visas detaļas nevar ievietot vienā slaidā. Ja kāds ir ziņkārÄ«gs, varat iet cauri kodola kodam un pārbaudÄ«t.

Kas Å”eit ir svarÄ«gs? PlÅ«smas etiÄ·etes lauka vērtÄ«ba mainās uz nejauÅ”u skaitli pēc katras RTO. Kā tas ietekmē mÅ«su neveiksmÄ«go TCP straumi?
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

SACK gadÄ«jumā nekas nav mainÄ«jies, jo mēs cenÅ”amies atkārtoti nosÅ«tÄ«t zināmu pazaudētu paketi. Tik tālu, labi.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Taču RTO gadÄ«jumā, ja esam pievienojuÅ”i plÅ«smas etiÄ·eti jaucējfunkcijai pakalpojumā ToR, satiksme var veikt citu marÅ”rutu. Un jo vairāk lidmaŔīnu, jo lielāka iespēja atrast ceļu, kuru neietekmē konkrētas ierÄ«ces avārija.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Viena problēma paliek - RTO. Cits marÅ”ruts, protams, tiek atrasts, bet tam tiek veltÄ«ts daudz laika. 200 ms ir daudz. Otrā parasti ir mežonÄ«ba. IepriekÅ” es runāju par taimautiem, kas konfigurē pakalpojumus. Tātad, sekunde ir taimauts, kas parasti iestata pakalpojumu lietojumprogrammas lÄ«menÄ«, un Å”ajā gadÄ«jumā pakalpojums bÅ«s pat samērā pareizs. Turklāt, es atkārtoju, reālā RTT mÅ«sdienu datu centrā ir aptuveni 1 milisekunde.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ko var darÄ«t ar RTO taimautiem? Taimautu, kas ir atbildÄ«gs par RTO datu pakeÅ”u zuduma gadÄ«jumā, var salÄ«dzinoÅ”i viegli konfigurēt no lietotāja vietas: ir IP utilÄ«ta, un viens no tās parametriem satur to paÅ”u rto_min. Ņemot vērā, ka, protams, RTO jāgriež nevis globāli, bet gan dotajiem prefiksiem, Ŕāds mehānisms izskatās diezgan darbojoÅ”s.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Tiesa, ar SYN_RTO viss ir nedaudz sliktāk. Tas ir dabiski pavirÅ”i. VērtÄ«ba ir fiksēta kodolā - 1 sekunde, un viss. JÅ«s to nevarat sasniegt no lietotāja vietas. Ir tikai viens veids.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

eBPF nāk palÄ«gā. VienkārÅ”oti sakot, tās ir mazas programmas C. Tās var ievietot āķos dažādās kodola steka un TCP steka izpildes vietās, ar kurām var mainÄ«t ļoti lielu skaitu iestatÄ«jumu. Kopumā eBPF ir ilgtermiņa tendence. Tā vietā, lai zāģētu desmitiem jaunu sysctl parametru un paplaÅ”inātu IP utilÄ«tu, kustÄ«ba notiek eBPF virzienā un paplaÅ”ina tā funkcionalitāti. Izmantojot eBPF, varat dinamiski mainÄ«t sastrēgumu kontroles un dažādus citus TCP iestatÄ«jumus.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Bet mums ir svarÄ«gi, lai ar tā palÄ«dzÄ«bu jÅ«s varētu sagrozÄ«t SYN_RTO vērtÄ«bas. Un ir publiski ievietots piemērs: https://elixir.bootlin.com/linux/latest/source/samples/bpf/tcp_synrto_kern.c. Kas Å”eit tiek darÄ«ts? Piemērs darbojas, bet pats par sevi ir ļoti aptuvens. Å eit tiek pieņemts, ka datu centra iekÅ”ienē mēs salÄ«dzinām pirmos 44 bitus, ja tie sakrÄ«t, tad atrodamies lÄ«dzstrāvas iekÅ”pusē. Un Å”ajā gadÄ«jumā mēs mainām SYN_RTO taimauta vērtÄ«bu uz 4 ms. To paÅ”u uzdevumu var veikt daudz graciozāk. Bet Å”is vienkārÅ”ais piemērs parāda, kas ir a) iespējams; b) salÄ«dzinoÅ”i viegli.

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ko mēs jau zinām? Tas, ka plakanā arhitektÅ«ra ļauj mērogot, mums izrādās ārkārtÄ«gi noderÄ«gi, kad ieslēdzam plÅ«smas etiÄ·eti uz ToR un iegÅ«stam iespēju plÅ«st ap problemātiskajām zonām. Labākais veids, kā samazināt RTO un SYN-RTO vērtÄ«bas, ir izmantot eBPF programmas. Paliek jautājums: vai ir droÅ”i izmantot plÅ«smas etiÄ·eti balansÄ“Å”anai? Un Å”eit ir nianse.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Pieņemsim, ka jums tÄ«klā ir pakalpojums, kas darbojas Anycast. Diemžēl man nav laika sÄ«kāk iedziļināties par anycast, bet tas ir izplatÄ«ts pakalpojums, kurā ir pieejami dažādi fiziski serveri uz vienas IP adreses. Un Å”eit ir iespējama problēma: RTO notikums var notikt ne tikai tad, kad satiksme Ŕķērso rÅ«pnÄ«cu. Tas var notikt arÄ« ToR bufera lÄ«menÄ«: kad notiek incast notikums, tas var notikt pat resursdatorā, kad resursdators kaut ko izlej. Kad notiek RTO notikums un tas maina plÅ«smas etiÄ·eti. Å ajā gadÄ«jumā datplÅ«sma var pāriet uz citu jebkuru apraides gadÄ«jumu. Pieņemsim, ka tas ir statuss anycast, tas satur savienojuma stāvokli ā€” tas var bÅ«t L3 Balancer vai kāds cits pakalpojums. Tad rodas problēma, jo pēc RTO TCP savienojums nonāk serverÄ«, kas par Å”o TCP savienojumu neko nezina. Un, ja mums nav stāvokļa koplietoÅ”anas starp anycast serveriem, tad Ŕāda trafika tiks pārtraukta un TCP savienojums pārtrÅ«ks.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Ko Å”eit var darÄ«t? JÅ«su kontrolētajā vidē, kurā iespējojat plÅ«smas etiÄ·eÅ”u lÄ«dzsvaroÅ”anu, jums ir jālabo plÅ«smas etiÄ·etes vērtÄ«ba, piekļūstot Anycast serveriem. VienkārŔākais veids ir to izdarÄ«t, izmantojot to paÅ”u eBPF programmu. Taču Å”eit ir ļoti svarÄ«gs moments ā€“ ko darÄ«t, ja nepārvaldāt datu centru tÄ«klu, bet esat telekomunikāciju operators? Tā ir arÄ« jÅ«su problēma: sākot ar noteiktām Juniper un Arista versijām, tās pēc noklusējuma iekļauj plÅ«smas etiÄ·eti hash funkcijā ā€” godÄ«gi sakot, man nesaprotama iemesla dēļ. Tas var izraisÄ«t TCP savienojumu pārtraukÅ”anu no lietotājiem, kuri izmanto jÅ«su tÄ«klu. Tāpēc es ļoti iesaku pārbaudÄ«t marÅ”rutētāja iestatÄ«jumus Å”ajā vietā.

Tā vai citādi, man Ŕķiet, ka esam gatavi pāriet uz eksperimentiem.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Kad ieslēdzām ToR plÅ«smas etiÄ·eti, sagatavojām aÄ£enta eBPF, kas tagad dzÄ«vo uz saimniekiem, nolēmām negaidÄ«t nākamo lielo neveiksmi, bet gan veikt kontrolētus sprādzienus. Mēs paņēmām ToR, kuram ir četras augÅ”upsaites, un samazinājām vienu no tiem. Viņi uzzÄ«mēja likumu, viņi teica - tagad jÅ«s zaudējat visas paketes. Kā redzat kreisajā pusē, mums ir pakeÅ”u monitorings, kas ir samazinājies lÄ«dz 75%, tas ir, tiek zaudēti 25% pakeÅ”u. Labajā pusē ir diagrammas ar pakalpojumiem, kas atrodas aiz Ŕī uzdevuma. Faktiski Å”ie ir satiksmes diagrammas savienojumiem ar serveriem, kas atrodas plauktā. Kā redzat, tās nogrima vēl zemāk. Kāpēc tie nogrima zemāk - nevis par 25%, bet dažos gadÄ«jumos par 3-4 reizēm? Ja TCP savienojums ir neveiksmÄ«gs, tas turpina mēģināt sasniegt, izmantojot bojāto interfeisu. To pastiprina tipiskā pakalpojuma darbÄ«ba DC iekÅ”ienē ā€” vienam lietotāja pieprasÄ«jumam tiek Ä£enerēti N pieprasÄ«jumi iekŔējiem pakalpojumiem, un atbilde tiks nosÅ«tÄ«ta lietotājam, vai nu tad, kad atbildēs visi datu avoti, vai arÄ« tad, kad tiek aktivizēts noildze. lietojumprogrammas lÄ«menis, kas vēl ir jākonfigurē. Tas ir, viss ir ļoti, ļoti slikti.
Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Tagad tas pats eksperiments, bet ar iespējotu plÅ«smas etiÄ·eti. Kā redzat, kreisajā pusē mÅ«su partiju uzraudzÄ«ba samazinājās par tiem paÅ”iem 25%. Tas ir pilnÄ«gi pareizi, jo par retranslācijām neko nezina, sÅ«ta paketes un vienkārÅ”i skaita piegādāto un pazaudēto pakeÅ”u attiecÄ«bu.

Un labajā pusē ir pakalpojumu grafiks. Å eit jÅ«s neatradÄ«sit problēmas locÄ«tavas efektu. DatplÅ«sma tajās paŔās milisekundēs plÅ«da no problēmas apgabala uz trim atlikuÅ”ajām augÅ”upsaitēm, kuras problēma neietekmēja. Mums ir tÄ«kls, kas dziedē pats par sevi.

Tīkls, kas dziedina pats sevi: Flow Label burvība un detektīvs ap Linux kodolu. Yandex pārskats

Å is ir mans pēdējais slaids, laiks izvērtēt. Tagad es ceru, ka jÅ«s zināt, kā izveidot paÅ”atjaunojoÅ”u datu centru tÄ«klu. Jums nevajadzēs iet cauri Linux kodola arhÄ«vam un meklēt tur Ä«paÅ”us ielāpus, jÅ«s zināt, ka Flow etiÄ·ete Å”ajā gadÄ«jumā atrisina problēmu, taču jums ir rÅ«pÄ«gi jāpieiet Å”im mehānismam. Un es vēlreiz uzsveru, ka, ja esat pārvadātājs, jums nevajadzētu izmantot plÅ«smas etiÄ·eti kā jaucējfunkciju, pretējā gadÄ«jumā jÅ«s pārtrauksit savu lietotāju sesijas.

Tīkla inženieriem ir jānotiek konceptuālai maiņai: tīkls nesākas ar ToR, nevis ar tīkla ierīci, bet ar resursdatoru. Diezgan spilgts piemērs ir tas, kā mēs izmantojam eBPF gan, lai mainītu RTO, gan lai fiksētu plūsmas etiķeti attiecībā uz anycast pakalpojumiem.

PlÅ«smas etiÄ·etes mehāniÄ·is noteikti ir piemērots citiem lietojumiem kontrolētajā administratÄ«vajā segmentā. Tā var bÅ«t satiksme starp datu centriem, vai arÄ« jÅ«s varat izmantot Ŕādu mehāniku Ä«paŔā veidā, lai kontrolētu izejoÅ”o trafiku. Bet es ceru, ka par to runāŔu nākamreiz. Liels paldies par jÅ«su uzmanÄ«bu.

Avots: www.habr.com