Qendrat moderne të të dhënave kanë qindra pajisje aktive të instaluara, të mbuluara nga lloje të ndryshme monitorimi. Por edhe një inxhinier ideal me monitorim të përsosur në dorë do të jetë në gjendje t'i përgjigjet saktë një dështimi të rrjetit në vetëm disa minuta. Në një raport në konferencën Next Hop 2020, unë paraqita një metodologji të projektimit të rrjetit DC, e cila ka një veçori unike - qendra e të dhënave shërohet vetë në milisekonda. Më saktësisht, inxhinieri e rregullon me qetësi problemin, ndërsa shërbimet thjesht nuk e vënë re.
Për shumë inxhinierë të rrjetit, një rrjet qendrash të dhënash fillon, natyrisht, me ToR, me një ndërprerës në raft. ToR zakonisht ka dy lloje lidhjesh. Të vegjëlit shkojnë te serverët, të tjerët - ka N herë më shumë prej tyre - shkojnë drejt shtyllave të nivelit të parë, domethënë në lidhjet e tij. Lidhjet ngjitëse zakonisht konsiderohen të barabarta dhe trafiku midis lidhjeve ngjitëse balancohet bazuar në një hash nga 5-tuple, i cili përfshin proto, src_ip, dst_ip, src_port, dst_port. Nuk ka surpriza këtu.
Më pas, si duket arkitektura e planit? Spinat e nivelit të parë nuk janë të lidhura me njëra-tjetrën, por janë të lidhura përmes superspines. Shkronja X do të jetë përgjegjëse për superspines; është pothuajse si një ndërlidhje.
Dhe është e qartë se, nga ana tjetër, tori janë të lidhur me të gjitha shtyllat e nivelit të parë. Çfarë është e rëndësishme në këtë foto? Nëse kemi ndërveprim brenda raftit, atëherë ndërveprimi, natyrisht, kalon përmes ToR. Nëse ndërveprimi ndodh brenda modulit, atëherë ndërveprimi ndodh përmes shtyllave të nivelit të parë. Nëse ndërveprimi është ndërmodular - si këtu, ToR 1 dhe ToR 2 - atëherë ndërveprimi do të kalojë nëpër shtyllat e nivelit të parë dhe të dytë.
Në teori, një arkitekturë e tillë është lehtësisht e shkallëzueshme. Nëse kemi kapacitet porti, hapësirë të lirë në qendrën e të dhënave dhe fibër të paravendosur, atëherë numri i korsive mund të rritet gjithmonë, duke rritur kështu kapacitetin e përgjithshëm të sistemit. Kjo është shumë e lehtë për t'u bërë në letër. Kështu do të ishte në jetë. Por historia e sotme nuk ka të bëjë me këtë.
Dua të nxirren përfundimet e duhura. Ne kemi shumë shtigje brenda qendrës së të dhënave. Ata janë të pavarur me kusht. Një rrugë brenda qendrës së të dhënave është e mundur vetëm brenda ToR. Brenda modulit, kemi numrin e shtigjeve të barabartë me numrin e korsive. Numri i shtigjeve ndërmjet moduleve është i barabartë me produktin e numrit të planeve dhe numrit të superspines në secilin plan. Për ta bërë më të qartë, për të kuptuar shkallën, unë do të jap numra që janë të vlefshëm për një nga qendrat e të dhënave Yandex.
Ka tetë avionë, secili avion ka 32 superspina. Si rezultat, rezulton se ka tetë shtigje brenda modulit, dhe me ndërveprim ndërmoduli ka tashmë 256 prej tyre.
Kjo do të thotë, nëse ne jemi duke zhvilluar Cookbook, duke u përpjekur të mësojmë se si të ndërtojmë qendra të dhënash tolerante ndaj gabimeve që shërojnë veten, atëherë arkitektura planare është zgjidhja e duhur. Ai zgjidh problemin e shkallëzimit, dhe në teori është e lehtë. Ka shumë rrugë të pavarura. Pyetja mbetet: si i mbijeton një arkitekturë e tillë dështimeve? Ka dështime të ndryshme. Dhe ne do ta diskutojmë këtë tani.
Le të "sëmuret" një nga superspinat tona. Këtu iu ktheva arkitekturës me dy plane. Ne do të qëndrojmë me këto si shembull sepse thjesht do të jetë më e lehtë të shihet se çfarë po ndodh me më pak pjesë lëvizëse. Lëreni X11 të sëmuret. Si do të ndikojë kjo në shërbimet që jetojnë brenda qendrave të të dhënave? Shumë varet nga fakti se si duket dështimi.
Nëse dështimi është i mirë, kapet në nivelin e automatizimit të së njëjtës BFD, automatizimi vendos me kënaqësi nyjet problematike dhe izolon problemin, atëherë gjithçka është në rregull. Kemi shumë shtigje, trafiku ridrejtohet menjëherë në rrugë alternative dhe shërbimet nuk do të vërejnë asgjë. Ky është një skenar i mirë.
Një skenar i keq është nëse kemi humbje të vazhdueshme, dhe automatizimi nuk e vëren problemin. Për të kuptuar se si kjo ndikon në një aplikacion, do të duhet të kalojmë pak kohë duke diskutuar se si funksionon TCP.
Shpresoj të mos trondit askënd me këtë informacion: TCP është një protokoll konfirmimi i transmetimit. Kjo do të thotë, në rastin më të thjeshtë, dërguesi dërgon dy pako dhe merr një mesazh kumulativ mbi to: "Kam marrë dy pako".
Pas kësaj, ai do të dërgojë edhe dy pako të tjera dhe situata do të përsëritet. Kërkoj falje paraprakisht për disa thjeshtëzime. Ky skenar është i saktë nëse dritarja (numri i paketave në fluturim) është dy. Natyrisht, në rastin e përgjithshëm nuk është domosdoshmërisht kështu. Por madhësia e dritares nuk ndikon në kontekstin e përcjelljes së paketave.
Çfarë ndodh nëse humbasim paketën 3? Në këtë rast, marrësi do të marrë paketat 1, 2 dhe 4. Dhe ai do t'i thotë në mënyrë eksplicite dërguesit duke përdorur opsionin SACK: "E dini, mbërritën tre, por mesi humbi." Ai thotë: "Ack 2, SACK 4".
Në këtë moment, dërguesi pa asnjë problem përsërit saktësisht paketën e humbur.
Por nëse paketa e fundit në dritare humbet, situata do të duket krejtësisht ndryshe.
Marrësi merr tre paketat e para dhe para së gjithash fillon të presë. Falë disa optimizimeve në pirgun TCP të kernelit Linux, ai do të presë për një paketë të çiftuar, përveç nëse flamujt tregojnë qartë se është paketa e fundit ose diçka e ngjashme. Do të presë derisa të skadojë afati i vonuar i ACK-së dhe më pas do të dërgojë një konfirmim në tre paketat e para. Por tani dërguesi do të presë. Ai nuk e di nëse pakoja e katërt ka humbur apo është gati të mbërrijë. Dhe për të mos mbingarkuar rrjetin, ai do të përpiqet të presë për një tregues të qartë se paketa është humbur, ose që afati i RTO të skadojë.
Çfarë është skadimi i RTO? Ky është maksimumi i RTT-së i llogaritur nga grumbulli TCP dhe një konstante. Çfarë lloj konstante është kjo, ne do të diskutojmë tani.
Por gjëja e rëndësishme është se nëse jemi përsëri të pafat dhe paketa e katërt humbet përsëri, atëherë RTO dyfishohet. Kjo do të thotë, çdo përpjekje e pasuksesshme nënkupton dyfishimin e afatit.
Tani le të shohim se me çfarë është e barabartë kjo bazë. Si parazgjedhje, RTO minimale është 200 ms. Ky është minimumi RTO për paketat e të dhënave. Për paketat SYN është ndryshe, 1 sekondë. Siç mund ta shihni, edhe përpjekja e parë për të ridërguar paketat do të zgjasë 100 herë më shumë se RTT brenda qendrës së të dhënave.
Tani le të kthehemi te skenari ynë. Çfarë po ndodh me shërbimin? Shërbimi fillon të humbasë paketat. Le të jetë shërbimi me fat në fillim dhe të humbasë diçka në mes të dritares, pastaj merr një SACK dhe ridërgon paketat që kanë humbur.
Por nëse fati i keq përsëritet, atëherë kemi një RTO. Çfarë është e rëndësishme këtu? Po, ne kemi shumë shtigje në rrjetin tonë. Por trafiku TCP i një lidhjeje të veçantë TCP do të vazhdojë të kalojë nëpër të njëjtin pirg të prishur. Humbjet e paketave, me kusht që ky X11 i yni magjik të mos fiket vetë, nuk çon në rrjedhjen e trafikut në zona që nuk janë problematike. Ne po përpiqemi të dorëzojmë paketën përmes së njëjtës pirg të thyer. Kjo çon në një dështim kaskadë: një qendër të dhënash është një grup aplikacionesh ndërvepruese dhe disa nga lidhjet TCP të të gjitha këtyre aplikacioneve fillojnë të degradohen - sepse superspine prek të gjitha aplikacionet që ekzistojnë brenda qendrës së të dhënave. Siç thotë fjala e urtë: po s'e ke mbathur kalin, kali çalë; kali u çalë - raporti nuk u dorëzua; raporti nuk u dorëzua - ne e humbëm luftën. Vetëm këtu numërimi është në sekonda nga momenti që lind problemi deri në fazën e degradimit që shërbimet fillojnë të ndjejnë. Kjo do të thotë që përdoruesit mund të humbasin diçka diku.
Ekzistojnë dy zgjidhje klasike që plotësojnë njëra-tjetrën. E para janë shërbimet që po përpiqen të vendosin kashtë dhe të zgjidhin problemin si ky: “Le të rregullojmë diçka në pirgun TCP. Le të bëjmë afate kohore në nivel aplikimi ose sesione të gjata TCP me kontrolle të brendshme shëndetësore.” Problemi është se zgjidhje të tilla: a) nuk shkallëzohen fare; b) janë kontrolluar shumë dobët. Kjo do të thotë, edhe nëse shërbimi konfiguron aksidentalisht pirgun TCP në një mënyrë që e bën atë më të mirë, së pari, nuk ka gjasa të jetë i zbatueshëm për të gjitha aplikacionet dhe të gjitha qendrat e të dhënave, dhe së dyti, ka shumë të ngjarë, nuk do ta kuptojë që është bërë saktë, dhe çfarë jo. Kjo do të thotë, funksionon, por funksionon dobët dhe nuk shkallëzohet. Dhe nëse ka një problem rrjeti, kush është fajtor? Sigurisht, NOC. Çfarë bën NOC?
Shumë shërbime besojnë se në NOC puna ndodh diçka e tillë. Por për të qenë i sinqertë, jo vetëm kaq.
NOC në skemën klasike është e angazhuar në zhvillimin e shumë sistemeve të monitorimit. Këto janë monitorim i kutisë së zezë dhe kutisë së bardhë. Rreth një shembulli të monitorimit të shtyllës kurrizore të kutisë së zezë Alexander Klimenko në Hop-in e fundit Next. Nga rruga, ky monitorim funksionon. Por edhe monitorimi ideal do të ketë një vonesë kohore. Zakonisht kjo është disa minuta. Pasi të fiket, inxhinierëve në detyrë u duhet kohë për të kontrolluar dyfish funksionimin e tij, për të lokalizuar problemin dhe më pas për të shuar zonën e problemit. Kjo do të thotë, në rastin më të mirë, trajtimi i problemit zgjat 5 minuta, në rastin më të keq, 20 minuta, nëse nuk është menjëherë e dukshme se ku ndodhin humbjet. Është e qartë se gjatë gjithë kësaj kohe - 5 ose 20 minuta - shërbimet tona do të vazhdojnë të vuajnë, gjë që ndoshta nuk është mirë.
Çfarë do të dëshironit vërtet të merrnit? Kemi shumë mënyra. Dhe problemet lindin pikërisht sepse flukset TCP që janë të pafat vazhdojnë të përdorin të njëjtën rrugë. Ne kemi nevojë për diçka që do të na lejojë të përdorim rrugë të shumta brenda një lidhjeje të vetme TCP. Duket se kemi një zgjidhje. Ekziston TCP, i cili quhet TCP me shumë rrugë, domethënë TCP për shtigje të shumta. Vërtetë, ajo u zhvillua për një detyrë krejtësisht të ndryshme - për telefonat inteligjentë që kanë disa pajisje rrjeti. Për të maksimizuar transferimin ose për të bërë modalitetin primar/backup, u zhvillua një mekanizëm që krijon fije (sesione) të shumta në mënyrë transparente për aplikacionin dhe ju lejon të kaloni ndërmjet tyre në rast të një dështimi. Ose, siç thashë, maksimizoni brezin.
Por këtu ka një nuancë. Për të kuptuar se çfarë është, do të duhet të shohim se si krijohen fijet.
Fijet janë instaluar në mënyrë sekuenciale. Fillimisht instalohet filli i parë. Fillimet e mëpasshme vendosen më pas duke përdorur cookie-n për të cilën është rënë dakord tashmë brenda atij thread. Dhe këtu është problemi.
Problemi është se nëse filli i parë nuk vendoset, filli i dytë dhe i tretë nuk do të lindin kurrë. Kjo do të thotë, TCP me shumë rrugë nuk zgjidh humbjen e një pakete SYN në rrjedhën e parë. Dhe nëse SYN humbet, TCP me shumë rrugë shndërrohet në TCP të rregullt. Kjo do të thotë që në një mjedis të qendrës së të dhënave nuk do të na ndihmojë të zgjidhim problemin e humbjeve në fabrikë dhe të mësojmë të përdorim shtigje të shumta në rast të një dështimi.
Çfarë mund të na ndihmojë? Disa prej jush kanë marrë me mend tashmë nga titulli se një fushë e rëndësishme në historinë tonë të mëtejshme do të jetë fusha e titullit të etiketës së rrjedhës IPv6. Në të vërtetë, kjo është një fushë që shfaqet në v6, nuk është në v4, ajo zë 20 bit dhe ka kohë që ka polemika për përdorimin e saj. Kjo është shumë interesante - pati mosmarrëveshje, diçka u rregullua brenda RFC, dhe në të njëjtën kohë u shfaq një zbatim në kernelin Linux, i cili nuk ishte i dokumentuar askund.
Ju ftoj të shkoni me mua për një hetim të vogël. Le të hedhim një vështrim në atë që ka ndodhur në kernel Linux gjatë viteve të fundit.
viti 2014. Një inxhinier nga një kompani e madhe dhe e respektuar i shton funksionalitetit të kernelit Linux varësinë e vlerës së etiketës së rrjedhës nga hash-i i prizës. Çfarë po përpiqeshin të rregullonin këtu? Kjo lidhet me RFC 6438, i cili diskutoi çështjen e mëposhtme. Brenda qendrës së të dhënave, IPv4 shpesh inkapsulohet në paketat IPv6, sepse vetë fabrika është IPv6, por IPv4 duhet disi të jepet jashtë. Për një kohë të gjatë kishte probleme me çelsat që nuk mund të shikonin nën dy tituj IP për të arritur në TCP ose UDP dhe për të gjetur src_ports, dst_ports atje. Doli që hash-i, nëse shikoni dy kokat e para të IP-së, doli të ishte pothuajse i rregulluar. Për të shmangur këtë, në mënyrë që balancimi i këtij trafiku të kapsuluar të funksionojë siç duhet, u propozua që të shtohet hash-i i paketës së kapsuluar me 5 dyfish në vlerën e fushës së etiketës së rrjedhës. Përafërsisht e njëjta gjë është bërë për skemat e tjera të kapsulimit, për UDP, për GRE, kjo e fundit përdori fushën GRE Key. Në një mënyrë apo tjetër, qëllimet këtu janë të qarta. Dhe të paktën në atë moment në kohë ato ishin të dobishme.
Në vitin 2015, një patch i ri vjen nga i njëjti inxhinier i respektuar. Ai është shumë interesant. Ai thotë sa vijon - ne do të rastësojmë hash-in në rast të një ngjarjeje negative të rrugëtimit. Çfarë është një ngjarje negative e rrugëtimit? Kjo është RTO që diskutuam më herët, domethënë humbja e bishtit të dritares është një ngjarje vërtet negative. Vërtetë, është relativisht e vështirë të merret me mend se kjo është ajo.
2016, një tjetër kompani me reputacion, po ashtu e madhe. Ai çmonton patericat e fundit dhe e bën atë në mënyrë që hash-i, të cilin më parë e bënim rastësisht, tani ndryshon për çdo ritransmetim SYN dhe pas çdo skadimi të RTO. Dhe në këtë letër, për herë të parë dhe të fundit, thuhet qëllimi përfundimtar - të sigurohet që trafiku në rast humbjesh ose bllokimi të kanaleve të ketë aftësinë të ridrejtohet butësisht dhe të përdorë shtigje të shumta. Sigurisht, pas kësaj ka pasur shumë botime, mund t'i gjeni lehtësisht.
Edhe pse jo, nuk mundesh, sepse nuk ka pasur asnjë botim të vetëm për këtë temë. Por ne e dimë!
Dhe nëse nuk e kuptoni plotësisht se çfarë është bërë, unë do t'ju them tani.
Çfarë u bë, çfarë funksionaliteti iu shtua kernelit Linux? txhash ndryshon në një vlerë të rastësishme pas çdo ngjarje RTO. Ky është rezultati shumë negativ i rrugëzimit. Hash-i varet nga ky txhash, dhe etiketa e rrjedhës varet nga hash-i skb. Këtu ka disa llogaritje mbi funksionet; të gjitha detajet nuk mund të vendosen në një rrëshqitje. Nëse dikush është kurioz, mund të kaloni kodin e kernelit dhe të kontrolloni.
Çfarë është e rëndësishme këtu? Vlera e fushës së etiketës së rrjedhës ndryshon në një numër të rastësishëm pas çdo RTO. Si ndikon kjo në rrjedhën tonë të pafat TCP?
Nëse ndodh një SACK, asgjë nuk ndryshon sepse ne po përpiqemi të ridërgojmë një paketë të njohur të humbur. Deri këtu mirë.
Por në rastin e RTO, me kusht që të kemi shtuar një etiketë të rrjedhës në funksionin hash në ToR, trafiku mund të marrë një rrugë tjetër. Dhe sa më shumë korsi, aq më e madhe është mundësia që ai të gjejë një shteg që nuk ndikohet nga një dështim në një pajisje specifike.
Një problem mbetet - RTO. Sigurisht, ka një rrugë tjetër, por shumë kohë humbet për këtë. 200 ms janë shumë. Një sekondë është absolutisht e egër. Më parë, kam folur për afatet e konfigurimit të shërbimeve. Pra, një sekondë është një timeout, i cili zakonisht konfigurohet nga shërbimi në nivelin e aplikacionit, dhe në këtë shërbimi madje do të jetë relativisht i drejtë. Për më tepër, e përsëris, RTT e vërtetë brenda një qendre moderne të dhënash është rreth 1 milisekonda.
Çfarë mund të bëni me afatet e RTO? Koha, e cila është përgjegjëse për RTO në rast të humbjes së paketave të të dhënave, mund të konfigurohet relativisht lehtë nga hapësira e përdoruesit: ekziston një mjet IP dhe një nga parametrat e tij përmban të njëjtin rto_min. Duke marrë parasysh që RTO, natyrisht, duhet të rregullohet jo globalisht, por për prefikset e dhëna, një mekanizëm i tillë duket mjaft i zbatueshëm.
Vërtetë, me SYN_RTO gjithçka është disi më keq. Është gozhduar natyrshëm. Kerneli ka një vlerë fikse prej 1 sekonde, dhe kaq. Nuk mund të arrish atje nga hapësira e përdoruesit. Ka vetëm një mënyrë.
eBPF vjen në shpëtim. E thënë thjesht, këto janë programe të vogla C. Ato mund të futen në grepa në vende të ndryshme gjatë ekzekutimit të stakut të kernelit dhe stekit TCP, me të cilin mund të ndryshoni një numër shumë të madh cilësimesh. Në përgjithësi, eBPF është një prirje afatgjatë. Në vend që të shkurtohen dhjetëra parametra të rinj sysctl dhe të zgjerohet shërbimi IP, lëvizja po shkon drejt eBPF dhe zgjeron funksionalitetin e saj. Duke përdorur eBPF, ju mund të ndryshoni dinamikisht kontrollet e mbingarkesës dhe cilësime të tjera të ndryshme TCP.
Por është e rëndësishme për ne që mund të përdoret për të ndryshuar vlerat SYN_RTO. Për më tepër, ekziston një shembull i postuar publikisht: . Çfarë është bërë këtu? Shembulli funksionon, por në vetvete është shumë i përafërt. Këtu supozohet se brenda qendrës së të dhënave krahasojmë 44 bitët e parë; nëse përputhen, atëherë jemi brenda qendrës së të dhënave. Dhe në këtë rast ne ndryshojmë vlerën e skadimit të SYN_RTO në 4ms. E njëjta detyrë mund të bëhet shumë më elegante. Por ky shembull i thjeshtë tregon se kjo është a) e mundur; b) relativisht e thjeshtë.
Çfarë dimë tashmë? Fakti që arkitektura e planit lejon shkallëzimin, rezulton të jetë jashtëzakonisht i dobishëm për ne kur aktivizojmë etiketën e rrjedhës në ToR dhe marrim aftësinë për të rrjedhur rreth zonave problematike. Mënyra më e mirë për të reduktuar vlerat RTO dhe SYN-RTO është përdorimi i programeve eBPF. Pyetja mbetet: a është e sigurt të përdoret një etiketë rrjedhëse për balancim? Dhe këtu ka një nuancë.
Supozoni se keni një shërbim në rrjetin tuaj që jeton në anycast. Fatkeqësisht, nuk kam kohë të hyj në detaje se çfarë është anycast, por është një shërbim i shpërndarë me serverë të ndryshëm fizikë të aksesueshëm përmes të njëjtës adresë IP. Dhe këtu është një problem i mundshëm: ngjarja RTO mund të ndodhë jo vetëm kur trafiku kalon përmes pëlhurës. Mund të ndodhë gjithashtu në nivelin e tamponit ToR: kur ndodh një ngjarje incast, mund të ndodhë edhe në host kur hosti derdh diçka. Kur ndodh një ngjarje RTO dhe ndryshon etiketën e rrjedhës. Në këtë rast, trafiku mund të shkojë në një shembull tjetër anycast. Le të supozojmë se ky është një anycast me status, ai përmban një gjendje lidhjeje - mund të jetë një balancues L3 ose ndonjë shërbim tjetër. Pastaj lind një problem, sepse pas RTO lidhja TCP arrin në server, i cili nuk di asgjë për këtë lidhje TCP. Dhe nëse nuk kemi ndarje të gjendjes midis serverëve anycast, atëherë një trafik i tillë do të hiqet dhe lidhja TCP do të prishet.
Çfarë mund të bëni këtu? Brenda mjedisit tuaj të kontrolluar, ku aktivizoni balancimin e etiketës së rrjedhës, duhet të regjistroni vlerën e etiketës së rrjedhës kur hyni në serverët anycast. Mënyra më e lehtë është ta bëni këtë përmes të njëjtit program eBPF. Por këtu është një pikë shumë e rëndësishme - çfarë të bëni nëse nuk përdorni një rrjet qendrash të dhënash, por jeni operator telekomi? Ky është gjithashtu problemi juaj: duke filluar me disa versione të Juniper dhe Arista, ato përfshijnë një etiketë rrjedhëse në funksionet e tyre hash si parazgjedhje - sinqerisht, për një arsye që është e paqartë për mua. Kjo mund të bëjë që ju të hiqni lidhjet TCP nga përdoruesit që kalojnë nëpër rrjetin tuaj. Kështu që unë rekomandoj shumë të kontrolloni cilësimet e ruterit tuaj këtu.
Në një mënyrë apo tjetër, më duket se jemi gati të kalojmë në eksperimente.
Kur aktivizuam etiketën e rrjedhës në ToR, përgatitëm agjentin eBPF, i cili tani jeton në hostet, vendosëm të mos prisnim për dështimin tjetër të madh, por të kryenim shpërthime të kontrolluara. Ne morëm ToR, i cili ka katër lidhje lart, dhe vendosëm pika në njërën prej tyre. Ata nxorën një rregull dhe thanë - tani po humbisni të gjitha paketat. Siç mund ta shihni në të majtë, kemi monitorim për pako, i cili ka rënë në 75%, domethënë 25% e paketave humbasin. Në të djathtë janë grafikët e shërbimeve që jetojnë pas këtij ToR. Në thelb, këto janë grafikët e trafikut të ndërfaqeve me serverët brenda raftit. Siç mund ta shihni, ato u ulën edhe më poshtë. Pse ranë më poshtë - jo me 25%, por në disa raste me 3-4 herë? Nëse lidhja TCP është e pafat, ajo vazhdon të përpiqet të arrijë përmes kryqëzimit të prishur. Kjo përkeqësohet nga sjellja tipike e shërbimit brenda DC - për një kërkesë përdoruesi, krijohen N kërkesa për shërbimet e brendshme dhe përgjigja do t'i shkojë përdoruesit ose kur të gjitha burimet e të dhënave përgjigjen, ose kur ndodh një afat në aplikacion. niveli, i cili ende duhet të konfigurohet. Kjo do të thotë, gjithçka është shumë, shumë e keqe.
Tani i njëjti eksperiment, por me vlerën e etiketës së rrjedhës të aktivizuar. Siç mund ta shihni, në të majtë monitorimi ynë i grupit ra me të njëjtin 25%. Kjo është absolutisht e saktë, sepse nuk di asgjë për ritransmetimet, dërgon pako dhe thjesht numëron raportin e numrit të paketave të dorëzuara dhe të humbura.
Dhe në të djathtë është orari i shërbimit. Këtu nuk do të gjeni efektin e një nyje problematike. Në të njëjtat milisekonda, trafiku rrodhi nga zona e problemit në tre lidhjet e mbetura që nuk u prekën nga problemi. Ne kemi një rrjet që shëron veten.
Ky është rrëshqitja ime e fundit, koha për ta përmbledhur. Tani, shpresoj se e dini se si të ndërtoni një rrjet qendrash të dhënash vetë-shëruese. Nuk do të keni nevojë të kaloni nëpër arkivin e kernelit Linux dhe të kërkoni për arna të veçanta atje; ju e dini që etiketa Flow në këtë rast e zgjidh problemin, por duhet t'i qaseni këtij mekanizmi me kujdes. Dhe e theksoj edhe një herë që nëse jeni operator telekomi, nuk duhet të përdorni etiketën e rrjedhës si funksion hash, përndryshe do të prishni seancat e përdoruesve tuaj.
Inxhinierët e rrjetit duhet t'i nënshtrohen një ndryshimi konceptual: rrjeti nuk fillon me ToR, jo me pajisjen e rrjetit, por me hostin. Një shembull mjaft i mrekullueshëm është se si ne përdorim eBPF si për të ndryshuar RTO ashtu edhe për të rregulluar etiketën e rrjedhës drejt shërbimeve anycast.
Mekanika e etiketës së rrjedhës është sigurisht e përshtatshme për aplikime të tjera brenda segmentit të kontrolluar administrativ. Ky mund të jetë trafiku ndërmjet qendrave të të dhënave, ose ju mund të përdorni mekanikë të tillë në një mënyrë të veçantë për të menaxhuar trafikun në dalje. Por unë do t'ju tregoj për këtë, shpresoj, herën tjetër. Faleminderit shume per vemendjen tuaj.
Burimi: www.habr.com